The Dilemma of HTTP POST or PUT!
Let's take a look at the dilemma of HTTP POST or PUT and explore how we use the HTTP methods to create, modify, or access the resources from the application.
Join the DZone community and get the full member experience.
Join For FreeWhen we develop a RESTFul application, we use the HTTP methods (verbs) to create, modify, or access the resources from the application. So, what are these HTTP methods anyway? They are nothing but defines an action that the HTTP request will perform on the server. These are the HTTP Verbs available to perform action:
- GET
- POST
- PUT
- PATCH
- DELETE
Most of these verbs are self-explanatory, right?
But, what about POST and PUT?
The most common answer is the POST for creating resources while PUT is for updating. However, this is how it is being used, but why?
In this article, I will try to explain the difference between POST and PUT.
POST and PUT can be used for inbound resources to the server, meaning either to create a new resource(s) and updating existing resource(s). One of the main differences between them is IDEMPOTENCY.
What Is IDEMPOTENCY?
IDEMPOTENCY is a feature of maintaining a single state of the resource in the server regardless of how many requests are being sent to create that particular resource.
For Ex:
{
id: 12,
first_name: 'Sovan',
last_name: 'Misra',
place: 'Hyderabad'
}
Even if we try to send multiple requests to create this myName Resource, only one resource would be created. This is idempotent!
Now that we have some idea about idempotency, let's understand that POST is non-idempotent, whereas PUT is idempotent. Meaning, when we make multiple requests using POST, more than one resource would be created, whereas in the case of PUT, it will update the same resource after creating the same on the first request.
Ideally, when we POST a request, the server creates the resource and responds back with a URI to access that resource, but for PUT, we have to send the request with the URI. If that resource is not found, then it will be created and responded back with the same URI or else if present, the resource is updated.
One more thing we have to maintain while doing a PUT request is to send a complete request, meaning with all its parameters to maintain idempotency, but in POST, we can send the partial resource to update it but with the resource identifier.
Ex:
PUT /my-name/12
{
id: 12,
first_name: 'SovanUpdated',
last_name: 'MisraUpdated',
place: 'Hyderabad'
}
POST /my-name/12
{
id: 12,
first_name: 'SovanUpdated'
}
Summary
Use POST when we do not know how to identify the resource and let the identifier be generated by the system ( HTTP POST /resources
) and let the user know that the resource has been created by sending "201 Created" along with the URI to access the resource ( http://localhost:8080/resources/
). The POST request can also be used to partially* update the resource by passing resource identifier and respond back with "200 Ok"
Use PUT when we have the resource identifier known ( HTTP POST /resources/
) so the system will create with that and respond back with URI with that identifier ( http://localhost:8080/resources/
).
The POST requests are non-idempotent and hence are not cached by default, and to do so, we have to explicitly set the caching in the headers. So be wise in choosing the request type.
NB: *Partial Updates can also be done by PATCH, which is also non-idempotent, but this is not made a standard yet.
Hope this helps in understanding the difference between POST and PUT.
Published at DZone with permission of Sovan Misra, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments