3 ms·
Question 1#: Is there a reason PATCH is used (or even needed?), instead of PUT to update records? (Create, Read, Update & Delete => POST, GET, PUT & DELETE) see
by velox_io 10y ago
Question 1#: Is there a reason PATCH is used (or even needed?), instead of PUT to update records?
(Create, Read, Update & Delete => POST, GET, PUT & DELETE) seem like a natural fit, why complicate things?
Question 2#: What is the consensus around custom verbs?
While I've never gone down this route, a few times I have been tempted.
- Falkon1313 10y agoRe #1, PATCH is useful because PUT requires that you replace the entire resource even if you just want to change one little thing and to do that safely, you need the now-current-latest representation of the full resource. A common case is looking at resource A, which is related to resource B (and therefore you have B's ID, but not its full data), you can patch resource B specifying just its ID and the change that you want to make without having to fetch the whole thing first. Also, PUT can conflict (or overwrite changes) if something else has altered the resource since you fetched it. PATCH is more granular, so you can make it a lot less likely to conflict or overwrite (in addition to being more efficient). Re #2, I don't know about consensus, but usually when I think that I could use a custom verb, some more thought reveals that I could instead use a standard verb on another resource that I haven't spec'd out yet (like the comments about having a 'transaction' resource representing details of a transaction instead of a 'transfer' verb).
- sopooneo 10y agoHypothetically, with PUT, whatever you send to the server should now comprise the entirety of that resource. So if all you PUT is a last name to /people/4335, then all of a sudden person 4335 consists of nothing more than a last name alone in the void, and not even blank fields beside. With PATCH, on the other hand, you can confidently send the value of just one updated field, without your users worrying about their metaphysical well-being.