Difference between post and put in REST style

 

Rest (representational state transfer) is a style of network service interfaces and is not a standard. for Web Services, rest is much more lightweight than soap (soap is a standard, not a style, it is much easier. I remember when I first came into contact with web services, all the materials came up with a lot of terms, soap, and WSDL, and all the headers were getting bigger, the rest mentioned later is much easier to understand. Although soap still has a place in enterprise-level web services, it is really embarrassing to say hello to people if it is not a rest service on the public internet, we often see that xx services are restful, but we have never heard that xx services are soapful.

Microsoft's support for rest is a bit late. Since net3.5, WCF can also provide restful interfaces. Of course, rest is not limited to Web Services, but web services can also be restful. Microsoft's ASP. net mvc Framework provides direct rest support.

Rest is just a style, not a standard, so some aspects are easy to misunderstand. For example, when creating and updating resources represented by a URI, http put or POST commands are used. There are four common HTTP commands for rest: Get, delete, put, and post. For get and delete, one is to get resources, the other is to delete resources, and there is no objection, the problem is put and post, both of which have modified the semantics of the specified URI. So which one is used?

Some hold that post should be used to create a resource, and put should be used to update a resource; some hold that put should be used to create a resource and post should be used to update a resource; another point is that you can use either put or post to create or update a resource. These ideas only show the style. In the debate, they only argue about which style is better. In fact, using put or post doesn't mean that it is the action of creating or updating resources. This is not a style issue, it is a semantic issue.

Rest is a style, but it still depends on the HTTP protocol. In HTTP, put is defined as the idempotent method, and post is not. This is a very important difference.

"Methods can also have the property of" idempotence "in that (aside from error or expiration issues) the side-effects of N> 0 identical requests is the same as for a single request."

In the above words, if a method is repeatedly executed multiple times, the results will be the same, that is, idempotent.

A simple example is to add a web API provided by a blog system. The mode is http: // superblogging/blogs/post/{blog-name}, which is very simple, replace {blog-name} with our blog name and send an http put or POST request to this URI. The HTTP body is a blog, which is a simple example of rest API. Should we use the put method or the POST method? It depends on whether the behavior of this rest service is idempotent. If we send two http: // superblogging/blogs/post/sample requests, what kind of behavior is the server side? If two blog posts are generated, it indicates that this service is not idempotent, because multiple use operations have a side effect. If the next request overwrites the first one, the service is idempotent. In the previous case, the POST method should be used. In the latter case, the put method should be used.

Maybe you will think that the difference between the two methods is no big deal, and there will be no problems if you use the wrong method, but if your service is put on the Internet, if you do not follow the HTTP protocol specifications, it may cause troubles to you. For example, Google crawler may also access your service. If a service that is not indempotent can be accessed using the indempotent method, the status of your server may be modified by the crawler, this should not happen.