If we pass all the fields of the resource in a PATCH request's body, it would overall act as a PUT request itself, i.e. update the whole resource. So what is the need for the PUT method?
What is the need for the PUT Method if we can update the whole resource in the PATCH request itself?
Asked
Active
Viewed 212 times
-1
Aayush Taneja
- 511
- 7
- 18
-
1This has been widely discussed before. I'd suggest reading [Put vs Patch methods in res API in real life scenarios](https://stackoverflow.com/questions/28459418/use-of-put-vs-patch-methods-in-rest-api-real-life-scenarios). The intro to the question covers some of the first differences. Answers cover other differences. Among other differences: PUT has capabilities that PATCH does not, such as creating a new resource. PATCH has capabilities that PUT does not such as updating only some properties of a resource without even knowing all the other property values. – jfriend00 Nov 09 '21 at 07:55
-
And, if you Google PUT vs PATCH, you'll find lots and lots more articles to read. – jfriend00 Nov 09 '21 at 07:56
-
Yes, you can use PATCH for most of what PUT can do, but there are subtle differences in the spec and some unique capabilities for each. Also read about idempotent for each - a PUT must be idempotent, a PATCH does not have to be (though it can be). – jfriend00 Nov 09 '21 at 08:15
1 Answers
1
PUT has stronger semantic guarantees than PATCH.
PUT is idempotent
A request method is considered idempotent if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.
If general purpose HTTP connectors know that a request has idempotent semantics, then they can do intelligent things with that information. For instance, on an unreliable network, a general purpose component can retry a PUT request if it times out waiting for a response.
PATCH, like POST, is not so tightly constrained; retrying a request isn't guaranteed to be risk free.
VoiceOfUnreason
- 52,766
- 5
- 49
- 91