Definitions:
-
PUT: This method asks for the enclosed data to be stored at the specified Request-URI. If that URI indicates an existing resource, the data should be seen as a modified version of what is currently stored. If the URI does not point to any resource, the server may create a new one at that location.
-
PATCH: This method requests that a specific set of updates be applied to the resource identified by the Request-URI.
Real-Life Example:
Consider a scenario where I POST to /accounts
with payload {name: 'johnDoe', email: '[email protected]'}
. The server then creates a resource and responds with a 201 status code and location /accounts/1
. Subsequently, a GET request to /accounts/1
retrieves {id: 1, name: 'johnDoe', email: '[email protected]'}
.
If I want to update my email address, this modification involves a set of changes, so I’d issue a PATCH request to /accounts/1
with the JSON {email: '[email protected]'}
. The server acknowledges this with a 200 status code.
Questions:
-
If PATCH is supposed to be non-idempotent and issuing the same PATCH request yields the same result (with my email updated), how is PATCH considered non-idempotent?
-
What fundamentally distinguishes PUT from PATCH? I’ve learned that PUT is meant for replacing an entire entity at a specific resource, necessitating the full entity data. What practical scenarios require replacing or overwriting an entity using PUT, and why is this operation categorized differently from updating or patching the entity? After the introduction of PATCH, using PUT for a single entity seems redundant. Am I mistaken?