Understanding of the concept of idempotent in HTTP

Idempotent is a very important concept in the design of distributed system

A idempotent method means that the result of a successful execution of a request does not depend on the number of times the method has been executed. Idempotent refers to the exact same result when you invoke the same function with the same value, which is its mathematical definition

If an operation with the same input does not change anything, then it is idempotent. However, if the operation changes an arbitrary state, say it records the last time of the request, then it is not idempotent.

Based on this principle, analyze the power of the methods in HTTP

The HTTP1.1 specification declares that the Get,head,put method is idempotent, but can also customize a doget method that is not idempotent (but should not), in other words, get must be idempotent, but doget not necessarily.

The HTTP get method is used to obtain resources and should not have side effects, so it is idempotent. For example: GET http://www.bank.com/account/123456, does not change the state of the resource, whether the call or n times have no side effects. Note that the emphasis here is on the same side effects as the N times, not the same as the results of each get. Get http://www.news.com/latest-news This HTTP request may get different results each time, but it does not produce any side effects, and is therefore sufficient to be idempotent.

The HTTP Delete method is used to delete resources with side effects, but it should satisfy idempotent. For example: Delete http://www.forum.com/article/4231, call once and n times to the system side effect is the same, that is, the deletion of the post ID 4231; therefore, the caller can call or refresh the page multiple times without worrying about causing an error.

The URI corresponding to the post is not the resource itself, but the recipient of the resource. For example, the semantics of post http://www.forum.com/articles is to create a post under Http://www.forum.com/articles, and the HTTP response should include the status of the post and the URI of the post. Two times the same post request creates two resources on the server side with different URIs, so the Post method is not idempotent. The URI for the put is the resource itself to be created or updated. For example, the semantics of PUT http://www.forum/articles/4231 is to create or update a post with ID 4231. The side effects of multiple put on the same URI are the same as a put, so the put method is idempotent.

There are actually two different ways to use the HTTP protocol: one is restful, it treats HTTP as an application-layer protocol, and more faithfully adheres to the various rules of the HTTP protocol, and the other is SOA, which does not completely treat HTTP as an application-layer protocol. Instead, the HTTP protocol is used as the Transport Layer protocol, and the application layer protocol is established on top of HTTP.

Using distributed transaction, we can guarantee the transactional of withdraw function by introducing middleware which supports distributed transaction. The advantage of distributed transactions is that the caller is simple and the complexity is given to the middleware to manage. The disadvantage is that the architecture is too heavyweight, easy to be tied to a particular middleware, not conducive to the integration of heterogeneous systems; On the other hand, distributed transactions, while guaranteeing the acid nature of transactions, do not provide the assurance of performance and availability.

The advantage of idempotent design over distributed transactions is its lightweight, easy adaptation to heterogeneous environments, and performance and availability aspects

Understanding of the concept of idempotent in HTTP