PUT vs POST in REST

from: http://stackoverflow.com/questions/630453/put-vs-post-in-rest

---

According to the HTTP/1.1 Spec: The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line In other words, POST is used to create. The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI." That is, PUT is used to create or update. So, which one should be used to create a resource? Or one needs to support both?

---

Overall:

Both PUT and POST can be used for creating.

You have to ask "what are you performing the action to?" to distinguish what you should be using. Let's assume you're designing an API for asking questions.  If you want to use POST then you would do that to a list of questions. If you want to use PUT then you would do that to a particular question.

Great both can be used, so which one should I use in my RESTful design:

You do not need to support both PUT and POST. 

Which is used is left up to you.  But just remember to use the right one depending on what object you are referencing in the request.

Some considerations:

• Do you name your URL objects you create explicitly, or let the server decide? If you name them then use PUT.  If you let the server decide then use POST.
• PUT is idempotent, so if you PUT an object twice, it has no effect.  This is a nice property, so I would use PUT when possible.
• You can update or create a resource with PUT with the same object URL
• With POST you can have 2 requests coming in at the same time making modifications to a URL, and they may update different parts of the object.

An example:

I wrote the following as part of another answer on SO regarding this:

POST:

Used to modify and update a resource

POST /questions/<existing_question> HTTP/1.1
Host: wahteverblahblah.com

Note that the following is an error:

POST /questions/<new_question> HTTP/1.1
Host: wahteverblahblah.com

If the URL is not yet created, you  should not be using POST to create it  while specifying the name.  This should  result in a 'resource not found' error  because <new_question> does not exist  yet.  You should PUT the <new_question>  resource on the server first.

You could though do something like  this to create a resources using POST:

POST /questions HTTP/1.1
Host: wahteverblahblah.com

Note that in this case the resource  name is not specified, the new objects  URL path would be returned to you.

PUT:

Used to create a resource, or  overwrite it.  While you specify the  resources new URL.

For a new resource:

PUT /questions/<new_question> HTTP/1.1
Host: wahteverblahblah.com

To overwrite an existing resource:

PUT /questions/<existing_question> HTTP/1.1
Host: wahteverblahblah.com

---

You can find assertions on the web that say

• POST should be used to create a resource, and PUT should be used to modify one
• PUT should be used to create a resource, and POST should be used to modify one

Neither is quite right.

---

Better is to choose between PUT and POST based on idempotence of the action.

PUT implies putting a resource - completely replacing whatever is available at the given URL with a different thing.  By definition, a PUT is idempotent.  Do it as many times as you like, and the result is the same. x=5 is idempotent.  You can PUT a resource whether it previously exists, or not (eg, to Create, or to Update)!

POST updates a resource, adds a subsidiary resource, or causes a change.  A POST is not idempotent, in the way that x++ is not idempotent.

---

By this argument, PUT is for creating when you know the URL of the thing you will create. POST can be used to create when you know the URL of the "factory" or manager for the category of things you want to create.

so:

POST /expense-report

or:

PUT  /expense-report/10929

---

POST to a URL creates a child resource at a server defined URL.

• PUT to a URL creates/replaces the resource in its entirety at the client defined URL.
• PATCH to a URL updates part of the resource at that client defined URL.

The relevant specification for PUT and POST is RFC 2616 §9.5ff.

POST creates a child resource, so POST to /items creates a resources that lives under the /items resource.  Eg. /items/1. Sending the same post packet twice will create two resources.

PUT is for creating or replacing a resource at a URL known by the client.

Therefore: PUT is only a candidate for CREATE where the client already knows the url before the resource is created. Eg. /blogs/nigel/entry/when_to_use_post_vs_put as the title is used as the resource key

PUT replaces the resource at the known url if it already exists, so sending the same request twice has no effect. In other words, calls to PUT are idempotent.

The RFC reads like this:

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,

Note: PUT has mostly been used to update resources (by replacing them in their entireties), but recently there is movement towards using PATCH for updating existing resources, as PUT specifies that it replaces the whole resource. RFC 5789.