# HTTP protocol learning # (11) Understanding HTTP idempotence

See the following section in the httpcomponent document:

1.4.1. Http Transport Safety

It is important to understand that the HTTP protocol is not well suited to all types of applications. HTTP is a simple request/response oriented protocol which was initially designed to support static or dynamically generated Content Retrieval. it has never been intended to support transactional operations. for instance, the HTTP server will consider its part of the contract fulfilled if it succeeds in processing and processing the request, generating a response and sending a status code back to the client. the server will make no attempt to roll back the transaction if the client fails to receive the response in its entirety due to a read timeout, a request cancellation or a system crash. if the client decides to retry the same request, the server will inevitably end up executing the same transaction more than once. in some cases this may lead to Application Data Processing uption or inconsistent application state.

Even though HTTP has never been designed to support transactional processing, it can still be used as a transport protocol for mission critical applications provided certain conditions are met.To ensure HTTP Transport Layer Safety the system must ensure the idempotency of HTTP methods on the application layer.

 

As a result, how can we understand the idempotency of HTTP methods? Search found blog http://www.cnblogs.com/weidagang2046/archive/2011/06/04/2063696.html, have a preliminary understanding of HTTP idempotence, reprinted archive.

 

HTTP-based Web APIs are currently the most popular distributed service provision method. We have seen more and more SOA or restful Web APIs in both large-scale Internet applications and enterprise-level architectures. Why is Web APIs so popular? In my opinion, it is largely due to the simple and effective HTTP protocol. HTTP is a distributed resource-oriented network application layer protocol. It is very simple for servers to provide web services or clients to consume Web Services. Coupled with the development of technologies and tools such as browsers, JavaScript, Ajax, JSON, and HTML5, the design of Internet application architecture shows that the traditional PHP, JSP, and ASP. net and other server-side dynamic web pages to web API + RIA (rich Internet applications) transition trend. Web APIs focus on providing business services. Ria focuses on user interfaces and interactive design, and the division of labor in these two fields is clearer. Under this trend, web API design will become a required course for server programmers. However, just as the simple Java language does not mean high-quality Java programs, simple HTTP does not mean high-quality Web APIs. To design high-quality Web APIs, You need to thoroughly understand the features of the distributed system and HTTP protocol.

 

Idempotence Definition

 

This article focuses on an important property of the HTTP protocol: idempotence (idempotence ). In the HTTP/1.1 specification, idempotence is defined:

 

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 terms of definition, the idempotence of the HTTP method means that one request and multiple requests to a resource should have the same side effects. Idempotence belongs to the semantic category. Just as the compiler can only help check syntax errors, HTTP norms cannot be defined by syntax means such as message format, this may be one of the reasons why it is not very valued. In fact, idempotence is a very important concept in distributed system design. The distributed nature of HTTP also determines that it plays an important role in HTTP.

 

Distributed Transaction vs Power Design

 

Why idempotence? Let's start with an example. Suppose there is a Remote API (which can be HTTP or not) that withdraws money from the account, and we will temporarily use the class function method to record it:

bool withdraw(account_id, amount)

 

The semantics of withdraw is to deduct the amount of amount from the account corresponding to account_id. If the deduction is successful, true is returned, and the account balance is reduced by amount. If the deduction fails, false is returned, and the account balance remains unchanged. It is worth noting that, compared with the local environment, we cannot easily assume the reliability of the distributed environment. A typical case is that the withdraw request has been correctly processed by the server, but the returned results of the server have been lost due to network and other reasons, so that the client cannot know the processing result. Some improper design may make the user think that the previous operation failed and then refresh the page, which leads to two calls of withdraw, the account is also deducted once more. 1:

 

Figure 1

 

The solution to this problem is to use distributed transactions to ensure the transaction of the withdraw function by introducing middleware that supports distributed transactions. The advantage of distributed transactions is that the caller is simple and the complexity is managed by middleware. The disadvantage is that, on the one hand, the architecture is too heavyweight and easily tied to specific middleware, which is not conducive to the integration of heterogeneous systems; on the other hand, distributed transactions can ensure the acid nature of transactions, however, performance and availability cannot be guaranteed.

 

Another more lightweight solution is Power Equality design. We can use some techniques to convert withdraw to power, such:

 

int create_ticket() bool idempotent_withdraw(ticket_id, account_id, amount)

The syntax of create_ticket is to obtain the unique processing id ticket_id generated by a server. It will be used to identify subsequent operations. The difference between idempotent_withdraw and withdraw is that it is associated with a ticket_id. An operation indicated by a ticket_id is processed only once, and the processing result of the first call is returned for each call. In this way, idempotent_withdraw is idempotent, and the client can safely call it multiple times.

 

A complete money Acquisition Process in a power-equality solution is divided into two steps: 1. Call create_ticket () to obtain ticket_id; 2. Call idempotent_withdraw (ticket_id, account_id, amount ). Although create_ticket is not idempotent, The Impact of create_ticket on the system status can be ignored in this design. In addition, idempotent_withdraw is idempotent, so any step fails or times out due to network or other reasons, the client can retry until the result is obtained. 2:

 

Figure 2

 

Compared with distributed transactions, idempotence is designed to be lightweight and easy to adapt to heterogeneous environments, as well as performance and availability. In some applications with high performance requirements, idempotent design is often the only choice.

 

Idempotence of HTTP

 

HTTP itself is a resource-oriented application layer protocol, but there are actually two different ways to use http: one is restful, which regards HTTP as an application layer protocol, the other is SOA, which does not fully regard HTTP as an application layer protocol, but uses HTTP as a transport layer protocol, then, an application layer protocol is built on HTTP. The HTTP idempotence discussed in this article mainly targets restful styles. However, as we can see in the previous section, idempotence is not a specific protocol, it is a feature of distributed systems. Therefore, idempotence should be considered in both SOA and restful web API design. The following describes the semantics and idempotence of http get, delete, put, and post methods.

The http get method is used to obtain resources without side effects, so it is idempotent. For example, GET requests. Note that the same side effects occur once and N times, rather than the same results for each get operation. GET requests.

The HTTP Delete method is used to delete resources, which has side effects, but must satisfy idempotence. For example, delete multiple.

Http post and put are confusing. The difference between post and put is easily mistaken for "post indicates creating resources, and put indicates updating resources". In fact, both can be used to create resources, the essential difference lies in idempotence. In the HTTP specification, post and put are defined as follows:

 

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 .... .. if a resource has been created on the origin server, the response shocould be 201 (created) and contain an entity which describes the status of the request and refers to the new resource, and a location header.

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 shocould 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.

 

The URI corresponding to post is not the created resource, but the resource receiver. For example: Post Signature. Two identical POST requests will create two resources on the server, which have different Uris. Therefore, the POST method does not have idempotence. The URI corresponding to put is the resource to be created or updated. For example, the syntax of put http://www.forum/articles/4231is the creator or updated to 4231. The side effects of multiple put operations on the same URI are the same as those of one put operation. Therefore, the put method has idempotence.

 

After introducing the semantics and idempotence of several operations, let's take a look at how to implement the previously mentioned withdrawal function through Web APIs. It is easy to use post/tickets to implement create_ticket; use put/accounts/account_id/ticket_id & amount = xxx to implement idempotent_withdraw. It is worth noting that the amount parameter should not be a part of the URI. The actual URI should be/accounts/account_id/ticket_id, and the amount should be placed in the Request body. This mode can be applied to many occasions, such as preventing accidental repeated posting on a Forum website.

 

Summary

 

The above briefly introduces the concept of idempotence, the method of replacing distributed transactions with idempotence design, and the semantics and idempotence of the main http methods. In fact, if we want to trace the source, idempotence is a concept in mathematics, which expresses the same results of N transformations and 1 transformations. Interested readers can learn more from Wikipedia.