services - what is the difference between an http put and post method




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

  1. GET: Retrieves data from the server. Should have no other effect.
  2. POST: Sends data to the server for creating a new entity. Often used when uploading a file or submitting a web form.
  3. PUT: Similiar to POST, but used to replace an existing entity.
  4. PATCH: Similar to PUT, but used to update only certain fields within an existing entity.
  5. DELETE: Removes data from the server.
  6. TRACE: Provides a way to test what 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 server about actual request method and ask about custom headers.
  8. HEAD: Returns only the response headers.
  9. CONNECT: Used by 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 session, so the data is unreadable to a proxy.

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


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.

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.


According to RFC, the difference between PUT and POST is in the Request URI. The URI identified by POST defines the entity that will handle the POST request. The URI in the PUT request includes the entity in the request. So, POST /v1/coffees/orders means to create a new resource and return an identifier to describe the resource. In contrast, PUT /v1/coffees/orders/1234 means to update a resource identified by "1234" if it exists; else create a new order and use the orders/1234 URI to identify it.

PUT and POST can both be used to create or update methods. The usage of the method depends on the idempotent behavior expected from the method as well as the location of the resource to identify it.


As far as i know, PUT is mostly used for update the records.

  1. POST - To create document or any other resource

  2. PUT - To update the created document or any other resource.

But to be clear on that PUT usually 'Replaces' the existing record if it is there and creates if it not there..


Others have already posted excellent answers, I just wanted to add that with most languages, frameworks, and use cases you'll be dealing with POST much, much more often than PUT. To the point where PUT, DELETE, etc. are basically trivia questions.


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


REST asks developers to use HTTP methods explicitly and in a way that's consistent with the protocol definition. This basic REST design principle establishes a one-to-one mapping between create, read, update, and delete (CRUD) operations and HTTP methods. According to this mapping:

• To create a resource on the server, use POST.

• To retrieve a resource, use GET.

• To change the state of a resource or to update it, use PUT.

• To remove or delete a resource, use DELETE.

More info: RESTful Web services: The basics from IBM


The difference between POST and PUT is that PUT is idempotent, that means, calling the same PUT request multiple times will always produce the same result(that is no side effect), while on the other hand, calling a POST request repeatedly may have (additional) side effects of creating the same resource multiple times.

GET : Requests using GET only retrieve data , that is it requests a representation of the specified resource

POST : It sends data to the server to create a resource. The type of the body of the request is indicated by the Content-Type header. It often causes a change in state or side effects on the server

PUT : Creates a new resource or replaces a representation of the target resource with the request payload

PATCH : It is used to apply partial modifications to a resource

DELETE : It deletes the specified resource

TRACE : It performs a message loop-back test along the path to the target resource, providing a useful debugging mechanism

OPTIONS : It is used to describe the communication options for the target resource, the client can specify a URL for the OPTIONS method, or an asterisk (*) to refer to the entire server.

HEAD : It asks for a response identical to that of a GET request, but without the response body

CONNECT : It establishes a tunnel to the server identified by the target resource , can be used to access websites that use SSL (HTTPS)





put