What's the difference between a POST and a PUT HTTP REQUEST?

Question

They both seem to be sending data to the server inside the body, so what makes them different?

Solution 1

HTTP PUT:

PUT puts a file or resource at a specific URI, and exactly at that URI. If there's already a file or resource at that URI, PUT replaces that file or resource. If there is no file or resource there, PUT creates one. PUT is idempotent, but paradoxically PUT responses are not cacheable.

HTTP 1.1 RFC location for PUT

HTTP POST:

POST sends data to a specific URI and expects the resource at that URI to handle the request. The web server at this point can determine what to do with the data in the context of the specified resource. The POST method is not idempotent, however POST responses are cacheable so long as the server sets the appropriate Cache-Control and Expires headers.

The official HTTP RFC specifies POST to be:

• Annotation of existing resources;
• Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;
• Providing a block of data, such as the result of submitting a form, to a data-handling process;
• Extending a database through an append operation.

HTTP 1.1 RFC location for POST

Difference between POST and PUT:

The RFC itself explains the core difference:

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.

Additionally, and a bit more concisely, RFC 7231 Section 4.3.4 PUT states (emphasis added),

4.3.4. PUT

The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload.

Using the right method, unrelated aside:

One benefit of REST ROA vs SOAP is that when using HTTP REST ROA, it encourages the proper usage of the HTTP verbs/methods. So for example you would only use PUT when you want to create a resource at that exact location. And you would never use GET to create or modify a resource.

Solution 2

Only semantics.

An HTTP PUT is supposed to accept the body of the request, and then store that at the resource identified by the URI.

An HTTP POST is more general. It is supposed to initiate an action on the server. That action could be to store the request body at the resource identified by the URI, or it could be a different URI, or it could be a different action.

PUT is like a file upload. A put to a URI affects exactly that URI. A POST to a URI could have any effect at all.

Solution 3

To give examples of REST-style resources:

POST /books with a bunch of book information might create a new book, and respond with the new URL identifying that book: /books/5.

PUT /books/5 would have to either create a new book with the ID of 5, or replace the existing book with ID 5.

In non-resource style, POST can be used for just about anything that has a side effect. One other difference is that PUT should be idempotent: multiple PUTs of the same data to the same URL should be fine, whereas multiple POSTs might create multiple objects or whatever it is your POST action does.

Solution 4

1. GET: Retrieves data from the server. Should have no other effect.
2. PUT: Replaces target resource with the request payload. Can be used to update or create a new resource.
3. PATCH: Similar to PUT, but used to update only certain fields within an existing resource.
4. POST: Performs resource-specific processing on the payload. Can be used for different actions including creating a new resource, uploading a file, or submitting a web form.
5. DELETE: Removes data from the server.
6. TRACE: Provides a way to test what the server receives. It simply returns what was sent.
7. OPTIONS: Allows a client to get information about the request methods supported by a service. The relevant response header is Allow with supported methods. Also used in CORS as preflight request to inform the server about actual the request method and ask about custom headers.
8. HEAD: Returns only the response headers.
9. CONNECT: Used by the browser when it knows it talks to a proxy and the final URI begins with https://. The intent of CONNECT is to allow end-to-end encrypted TLS sessions, so the data is unreadable to a proxy.

Solution 5

PUT is meant as a a method for "uploading" stuff to a particular URI, or overwriting what is already in that URI.

POST, on the other hand, is a way of submitting data RELATED to a given URI.

Refer to the HTTP RFC

View more solutions

Comments

[Shaheen Zahedi]

Does this answer your question? PUT vs. POST in REST

[ChanGan]

Hi Bhollis, What will happen, if I use POST /books/5? will it throw resource not found?

[Martin Andersson]

I feel the idempotency is the most distinguishing and important difference between PUT and POST

[TaylorMac]

That which implies a certain function may not actually

[rdiachenko]

Hi ChanGan, here's an explanation which Wikipedia gives about your "POST /books/5" case: "Not generally used. Treat the addressed member as a collection in its own right and create a new entry in it."

[Kishore]

What is a record in this context? The question is about HTTP Request.

[tooluser]

This seems pointlessly rude, and pedantic in a less-than-useful way. In the example of a PUT you cite, the new entity is, in a RESTful api, a 'new' record - and accessible at that location. It's questionable whether it's a good design choice to allow sub-members be mutable like that (I think it's not ideal), but even were it, you're using a subspecies to attack a lot of useful information. Most of the time, the description as it is usually stated is a great statement of both the RFC's content, summarized, and a statement of usual and customary practice. Also, it won't hurt you to be polite.

[houcros]

I read in the specs that If the Request-URI does not point to an existing resource [...] the origin server *can* create the resource with that URI. So an implementation of PUT that refuses to create a resource if not present would be correct, right? If so, does this happen in practice? Or implementations usually also create on PUT?

[Beefster]

I think you have PUT and POST backwards

[Ashish Shetkar]

some additional exception which makes the difference very clear is at next URL - dzone.com/articles/put-vs-post

[Beefster]

No. PUT is for actually placing literal content at a URL and it rarely has its place in a REST API. POST is more abstract and covers any sort of adding content that doesn't have the semantics of "Put this exact file at this exact URL".

[Beefster]

This cannot be upvoted enough. PUT has no place in a REST API. Most of the time, POST indicates the correct semantics.

[Aditya Pednekar]

What would POST do if the document/resource is already present? Will it throw an error, or will it just go off OK?

[Roni Axelrad]

What I don't understand is how to implement the idempotency of PUT. in general, most API's will be using auto generation of an ID in case of creating a new resource. and in PUT, you should create a resource if it doesn't exists, but use the ID specified in the URI, but how can you do that if the id generation method is set to be automatic ???

[Drazen Bjelovuk]

So in a nutshell: The URI in a POST request identifies the resource that will handle the enclosed entity. The URI in a PUT request identifies the entity itself.

[William T Froggard]

Not said well, but indeed an accurate interpretation of the RFCs. The web developer world is quite a swamp of misinformation, it seems.

[Mosia Thabo]

@Beefster There's no such thing as 'POST Indicates'. Najeebul made a great point here. How do you figure what it indicates? except that you just use it because you've always used it that way since the first day you learned it but don't really know why you should use it compared to the others?

[nCardot]

Responses to POST method are not cacheable, UNLESS the response includes appropriate Cache-Control or Expires header fields

[Marinos An]

There are also some security-related differences: see my answer below

[Marthinus Engelbrecht]

@RoniAxelrad I was wondering about this myself. But I think the idea is that you should never create a duplicate resource ever. So for example if you wanted to store a transaction as a "resource" using api.example.com/payments and the body of 2 requests are exactly the same, why are you storing them both and generating unique primary keys? Are you possible processing duplicate requests? Should you maybe reconsider your design?

[variable]

Is CONNECT fired prior to each request when using https?

[Tommy]

this answer gives the impression that PUT and POST can be defined on the same resource, however the other difference next to idempotency is who controls the ID space. In PUT, the user is controlling the ID space by creating resources with a specific ID. In POST, the server is returning the ID that the user should reference in subsequent calls like GET. The above is weird because its's a mix of both.

[Ketan R]

Information given about PUT and POST is not right in this answer. PUT can be used to create a new entity as well as update an existing entity. POST is more generic and can be used to perform similar action like in PUT or can be used to perform any other action as well on the incoming entity (with side effects) and ideally, PUT should be idempotent where as POST may or may not be idempotent

[Slawomir Brzezinski]

Re: "paradoxically PUT responses are not cacheable". Perhaps worth expanding the paradox that what can be cacheable in PUTs are REQUESTs: The 2014's RFC 7231 (one of RFCs that obsolete the 1999's RFC 2616) mentions here that PUT allows a user agent to know when the representation body it has in memory remains current, i.e. the server MUST NOT send ... an ETag or Last-Modified ... unless the request's representation was saved without any transformation.There may not be many clients with such cache but the servers should follow spec.

[Maggyero]

−1 because in addition to update, PUT is also used to create a target resource (the resource identified by the request URI), contrary to POST which cannot create a target resource because it is not a CRUD operation on the resources’ states (data management) but a process operation (cf. RFC 7231). The process may create a resource but different from the target resource so that does make it a CRUD operation.

[Ben Seidel]

This is by far the best and most accurate explanation for Put and Post. It's the only one that talks about the client being able supply a meaningful URI to the resultant resource.

[RegarBoy]

Here's not a place where you share "As far as I know" type opinions. We need brief, documental answers.

[dpelisek]

Is every request that does not change the server's state a GET request? For example an endpoint that identifies keywords from a text sent as the request's body - is such an endpoint GET endpoint?

[Long Nguyen]

@dpelisek There is no request body in GET method