Page Title | Decisions |
---|---|
No decisions found |
Objective
The document provides a comprehensive deep dive into the PATCH and PUT operations as per the RESTful principles. We compare the two operations and to find out the major differences in their implementations and best practices to resolve the issues found in the “Update node leaves” and “Replace node leaves” APIs in CPS
Comparison of PATCH and PUT based on RESTful principles
Aspect | PATCH (Update) | PUT (Replace) |
---|---|---|
Purpose | PATCH is used to update specific fields of a data, while leaving the other fields unchanged. | PUT is used to replace the entire resource with new data. Any fields that are not included in the replacement payload are either set to a default value or removed. |
Payload Format |
|
|
Impact on server state | PATCH only modifies the specified fields sent as part of the payload. The remaining fields are left untouched | PUT overwrites the entire data. Fields not provided in the payload are removed. |
HTTP response codes |
|
|
Idempotency | PATCH is not always Idempotent as sending the same request multiple times may result in same resource state for the updated fields. But in some scenarios, this may not be true. | PUT is Idempotent, it means that, regardless of how many times an action is performed, the results will be the same as the first time. |
Idempotency Example | If a PUT request is modifying a counter, then sending the same request multiple times will reset the counter with each request. Whereas the same is not true for PATCH | If we issue a POST request several times, it will create multiple resources with the same content. On the contrary, if we issue the same PUT request multiple times, it will not have any effects on the specified resource, beyond the first time. This is because the POST request will create a new resource every time whereas the PUT request will keep overwriting the same resource. |
Atomicity | PATCH is usually non-atomic because it updates specific fields individually while others are unaffected. | PUT is an atomic operation because either whole resource is updated or no change occurs. |
Overhead | Lower overhead because only fields being updated are sent as part of request. | Higher overhead because all the fields are sent as part of request, even the ones not changed. |
Handling Creation of a new resource using PATCH
In RESTful APIs, the PUT method is commonly used to create a new resource if it doesn't exist.
According to RFC 5789, which defines the PATCH method, if the target resource does not exist, using PATCH to create new resources is generally not recommended. The primary purpose of PATCH is to apply partial modifications to existing resources, and its behavior when the resource doesn't exist can be unpredictable or inconsistent across different implementations.
Handling scenario where a new resource is provided as part of PATCH
Conflicting state: Can be specified with a 409 (Conflict) status code when the request cannot be applied given the state of the resource. For example, if the client attempted to apply a structural modification and the structures assumed to exist did not exist (with XML, a patch might specify changing element ’foo’ to element ’bar’ but element ’foo’ might not exist).
Based on the above abstract from RFC 5789, when a PATCH request is received, and the server determines that the resource does not exist, the server may return a 409 Conflict to indicate that the request cannot be fulfilled due to a conflict with the current state of the server. This response code is appropriate when the semantics of the patch document do not permit resource creation via a PATCH request.
Examples of PATCH operation
Description | Original Server State | PATCH payload | Server state after PATCH operation | Response Code |
---|---|---|---|---|
Updating a leaf node | { | { | { | 200 Ok |
Updating a leaf and a leaf list | { | { | { | 200 OK |
Updating a leaf while also adding a new list item with key "title": "The Gruffalo" in the list node books | { | { | { | 409 Conflict |
Updating leaves in multiple nodes | { | { | { | 200 OK |
Examples of PUT operation
Description | Original Server State | PATCH payload | Server state after PATCH operation | Response |
---|---|---|---|---|
Replacing a leaf node | { | { | { | 200 OK |
Replacing a leaf node and entire list | { | { | { | 200 OK |
Using PUT to create a new list | { | { | { | 201 Created |
Using PUT to add a new list item | { | { | { | 201 Created |
Replacing an entire list with a new list item | { | { | { | 200 OK |
Replacing entire leaf list using PUT | { | { | { | 200 OK |