Why use the HTTP PUT and DELETE methods instead of POST?

Question

new_story GET /story/new(.:format) {:action=>"new", :controller=>"stories"} edit_story GET /story/edit(.:format) {:action=>"edit", :controller=>"stories"} story GET /story(.:format) {:action=>"show", :controller=>"stories"} PUT /story(.:format) {:action=>"update", :controller=>"stories"} DELETE /story(.:format) {:action=>"destroy", :controller=>"stories"} POST /story(.:format) {:action=>"create", :controller=>"stories"} 

In web development, which I did with other technologies, I have ever used only the GET and POST methods, but with RESTful routes in Rails, by default, the PUT and DELETE methods are used for update and destroy actions. What is the advantage or necessity of using PUT and DELETE ? I guess these methods are just another way to do POST - but why not just stick to POST ?

Answer 1

The advantage is mostly semantic and can also simplify URLs. Different HTTP methods are mapped to different actions:

 POST => create a new object DELETE => delete an object PUT => modify an object GET => view an object 

Then, theoretically, you can use the same URL, but interact with it using different methods; The method used to access the resource determines the actual type of operation.

In practice, however, most browsers only support HTTP GET and POST. Rails uses some trickery in HTML forms to act as if a PUT or DELETE request was sent, although Rails still uses GET or POST for these methods. (This explains why you might not have used DELETE or PUT on other platforms.)

Answer 2

Here is the "methods" section of the HTTP 1.1 specification ; it defines many methods, and they all have different advantages and trade-offs. POST is the most flexible, but the tradeoffs are numerous: it is not cachable (so the rest of the Internet cannot help you scale), it is not safe or idempotent, so the client cannot just resubmit its error, and it is no longer clear what you are trying to execute (because it is so flexible). I am sure there are others, but that should be enough. Given all this, if the HTTP specification defines a method that does exactly what you want your request to do, there is no reason to send POST instead.

The reason for POST so common that, at least historically, web browsers only supported GET and POST . Because GET defined as safe and idempotent (although many applications do not adhere to this), the only safe way to modify data was to send a POST . With the growing number of AJAX clients and non-browsers, this is no longer the case.

BTW, the @mipadi mapping gives a standard mapping, but it is not the only one valid. For example, Amazon S3 uses PUT to create resources. The only reason for using POST is that the client does not have sufficient knowledge to create the resource, for example, you return your resources using a relational database and use artificial surrogate keys.

Answer 3

This would be like asking why “delete” a file, if you can just set its contents to zero bytes, and the file system will simply consider it a deletion. HTTP supported verbs other than GET / POST, but the way SOAP evolved distorted the original meaning of these verbs. REST is a simpler approach to the basics that uses verbs because they were intended instead of inventing some new concept of the verb inside the payload.

Answer 4

I just wanted to add something to the accepted answer because its definition of http verbs is wrong. They all have a specification that “should” be followed, and you can create / update / delete with multiple http verbs based on the specifications.

I'm going to highlight some important points in RFC 2616 from W3

I am going to start with PUT because, in my opinion, it is most confusing.

• PUT is used for both create/update PUT updates by completely replacing the resource on the server with the resource sent in the request

for example

You make this call to my API

 PUT /api/person { Name: John, email: [e-mail] } 

my server has this resource living on the server

 { Name: Jane, email: [e-mail] } 

Now my existing resource is completely replaced by what you sent, and this is what I have on my server.

 { Name: John, email: [e-mail] } 

So if you PUT and only send an email in the body

 PUT /api/person { email: [e-mail] } 

My server will completely replace the entity

 { Name: Jane, email: [e-mail] } 

FROM

 { email: [e-mail] } 

And the name will disappear. Partial updates are for PATCH but I still use POST for this.

• One of the main reasons why we create/update with put is because it is idempotent.

This is just a fancy term, and its main definition is that several identical requests are the same for one request.

example

Suppose I have a PUT file in api/file if the source server does not find this file, it will create it. If he finds the file, it will completely replace the old file with the one I sent. This ensures that one file is created and updated. If the file does not exist, and you call PUT 5 times, the first time it creates the file, and the remaining 4 times it replaces the file with what you transfer. If you call POST 5 times, 5 files will be created to create it.

• You PUT to that exact URI. If you don't you have to send a 301 (Moved Permanently) to the user and allow then make a choice whether or not to redirect the request. Most times the server you PUT to usually hosts the resource and takes care of updating it

These are the highlights when using PUT

Regarding POST

• You can also create/update and then some...

As I mentioned above, there are several key differences.

• The post is more general. In which cases? some other examples include a gateway to other protocols, it can take a response and send it to some data processor in the middle of the same day, or it can extend some functionality.
• The message does not have the “Exact URI or Notification” restriction, for example, POST can add a resource to an existing collection and decide where it is stored.

What about Delete Why don't I just have a POST ?

When you DELETE , the server SHOULD NOT respond successfully unless you delete the resource or move it to an inaccessible place while sending the response .

Why is it important? What if you call DELETE but the resource must go through "APPROVAL" before deleting? If the deletion can be rejected, you cannot send a successful error code, and if you really follow the basic specifications, this will confuse the caller. Just an example, I'm sure you can think of many others.

I just highlighted some of the main points when to use common Http verbs