Having recently converted our remaining PUT routes to PATCH I thought it would be nice to unify and formalize some of the differing practices in the API.
I believe that some of these formalizations could benefit our backend testing and frontend implementations.
If PATCH returns the same value as GET, and is the same route, then frontend
wouldn't need to re-fetch updated entities (not sure if we do this often, I've seen it a good deal in past lives)
could reuse types and code used by the original GET
would (theoretically) need to manage less state since it could just trust what PATCH yields rather than having it's own duplicate state store to maintain
These formalizations are nice for the backend because
we should be able to generate tests from a description of the fields a PATCH expects and expected outcomes thereabouts
allowing for empty PATCH objects and re-fetching would allow us to implement GET /some/route/123 as PATCH {} /some/route/123, or, conversely, we could implement the re-fetching using the GET (though that's not really a benefit).
Note that our current PATCH endpoints do not conform to these guidelines, in many cases. If this guideline is accepted I will file debt for the places that don't conform for the backend guild to prioritize.
mjgpy3
commented
3 years ago
Having recently converted our remaining
PUTroutes toPATCHI thought it would be nice to unify and formalize some of the differing practices in the API.I believe that some of these formalizations could benefit our backend testing and frontend implementations.
If
PATCHreturns the same value asGET, and is the same route, then frontendGETPATCHyields rather than having it's own duplicate state store to maintainThese formalizations are nice for the backend because
PATCHexpects and expected outcomes thereaboutsPATCHobjects and re-fetching would allow us to implementGET /some/route/123asPATCH {} /some/route/123, or, conversely, we could implement the re-fetching using theGET(though that's not really a benefit).Note that our current
PATCHendpoints do not conform to these guidelines, in many cases. If this guideline is accepted I will file debt for the places that don't conform for the backend guild to prioritize.