Shulou(Shulou.com)06/01 Report--

This article shows you how the idempotent concept and application of HTTP is. The content is concise and easy to understand. It will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Web API based on HTTP protocol is the most popular way to provide distributed services. Whether in large-scale Internet applications or enterprise-level architecture, we have seen more and more SOA or RESTful Web API. Why is Web API so popular? I think it is largely due to the simple and effective HTTP protocol. HTTP protocol is a distributed resource-oriented network application layer protocol, whether the server provides Web services or the client consumes Web services is very simple. Coupled with the development of technologies and tools such as browser, Javascript, AJAX, JSON and HTML5, Internet application architecture design shows a transition trend from traditional server-side dynamic web pages such as PHP, JSP, ASP.NET to Web API + RIA (Rich Internet applications). Web API focuses on providing business services, while RIA focuses on user interface and interaction design, making the division of labor between the two areas clearer. Under this trend, Web API design will become a required course for server-side programmers. However, just as a simple Java language does not mean high-quality Java programs, a simple HTTP protocol does not mean high-quality Web API. In order to design a high-quality Web API, it is necessary to deeply understand the characteristics of distributed systems and HTTP protocols.

Idempotent definition

What we want to discuss is an important property of HTTP protocol: idempotency (Idempotence). In the HTTP/1.1 specification, idempotency is defined as:

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.

By definition, the idempotency of the HTTP method means that requesting a resource once and multiple times should have the same side effects. Idempotency belongs to the semantic category, and just as the compiler can only help check for syntax errors, the HTTP specification has no way to define it through grammatical means such as message formats, which may be one of the reasons why it is not taken seriously. But in fact, idempotence is a very important concept in distributed system design, and the distributed nature of HTTP also determines that it plays an important role in HTTP.

Distributed transaction vs idempotent design

Why do we need idempotency? Let's start with an example. Suppose there is a remote API (either HTTP or not) that withdraws money from the account, and we temporarily write it down as a class function.

Bool withdraw (account_id, amount)

The semantics of withdraw is to deduct the amount of amount from the account corresponding to account_id; return true if the deduction is successful, and return false if the account balance decreases amount; if the deduction fails, 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 situation is that the withdraw request has been correctly processed by the server, but the return result of the server has been lost due to network and other reasons, resulting in the client can not know the processing result. If it is on a web page, some inappropriate design may make the user think that the last operation failed and then refresh the page, resulting in two calls to withdraw and an extra deduction from the account.

The first solution to this problem is to adopt distributed transactions and to ensure the transactionality of withdraw functions by introducing middleware that supports distributed transactions. The advantage of distributed transactions is that it is simple for callers, and the complexity is managed by middleware. The disadvantage is that on the one hand, the architecture is too heavyweight, which is easy to be tied to specific middleware, which is not conducive to the integration of heterogeneous systems; on the other hand, although distributed transactions can guarantee the ACID nature of transactions, they can not provide performance and availability guarantee.

Another more lightweight solution is idempotent design. The withdraw above is obviously not idempotent, but we can use some techniques to make it idempotent, such as:

Int create_ticket (); bool idempotent_withdraw (ticket_id, account_id, amount)

The semantics of create_ticket is to get a unique processing number ticket_id generated on the server side, which will be used to identify subsequent operations. The difference between idempotent_withdraw and withdraw is that a ticket_id is associated. The operation represented by a ticket_id will only be processed once at most, and each call will return the processing result of the first call. In this way, the idempotent_withdraw is idempotent, and the client can safely call it multiple times.

In the idempotent solution, a complete withdrawal process is broken down into two steps: 1. Call create_ticket () to get ticket_id;2. Call idempotent_withdraw (ticket_id, account_id, amount). Although create_ticket is not idempotent, in this design, its impact on the state of the system can be ignored, and idempotent_withdraw is idempotent, so any step that fails or times out due to network and other reasons, the client can retry until the result is obtained.

Compared with distributed transactions, idempotent design has the advantage of lightweight, easy to adapt to heterogeneous environment, as well as performance and availability. In some applications with high performance requirements, idempotent design is often the only choice.

The idempotency of HTTP

HTTP protocol itself is a resource-oriented application layer protocol, but there are actually two different ways to use HTTP protocol: one is RESTful, which regards HTTP as an application layer protocol and faithfully abides by various provisions of HTTP protocol; the other is SOA, which does not completely regard HTTP as an application layer protocol, but regards HTTP protocol as a transport layer protocol, and then establishes its own application layer protocol on HTTP. The HTTP idempotency discussed in this article is mainly aimed at the RESTful style, but as you can see in the previous section, idempotency is not a characteristic protocol, it is a characteristic of distributed systems; therefore, idempotency should be considered in both SOA and RESTful Web API design. The following describes the semantics and idempotency of the four main methods: HTTP GET, DELETE, PUT, and POST.

The HTTP GET method is used to get resources and should have no side effects, so it is idempotent. For example, GET http://www.bank.com/account/123456 does not change the state of the resource, regardless of whether it is called once or N times without side effects. Note that it is emphasized here that once and N times have the same side effects, rather than the same results of each GET. The GET http://www.news.com/latest-news HTTP request may get different results each time, but it does not produce any side effects itself, so it is idempotent.

The HTTP DELETE method is used to delete resources and has side effects, but it should be idempotent. For example, DELETE http://www.forum.com/article/4231, calling once and N times have the same side effect on the system, that is, deleting posts with an id of 4231; therefore, callers can call or refresh the page multiple times without having to worry about introducing errors.

It is easy to confuse HTTP POST and PUT. The difference between POST and PUT is easily mistaken for "POST for creating resources and PUT for updating resources"; in fact, both can be used to create resources, and the more essential difference is in terms of idempotency. POST and PUT are defined in the HTTP specification 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 SHOULD 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 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.

The URI corresponding to the POST is not the created 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. The HTTP response should include the creation status of the post and the URI of the post. Two identical POST requests create two resources on the server side, which have different URI;, so the POST method is not idempotent.

The URI corresponding to 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 posts with an ID of 4231. The side effect of multiple PUT on the same URI is the same as that of one PUT; therefore, the PUT method is idempotent.

After introducing the semantics and idempotency of several operations, let's take a look at how to implement the aforementioned withdrawal function in the form of Web API. Very simply, use POST / tickets to implement create_ticket; and PUT / accounts/account_id/ticket_id&amount=xxx to implement idempotent_withdraw. It is worth noting that strictly speaking, the amount parameter should not be part of the URI, the real URI should be / accounts/account_id/ticket_id, and the amount should be placed in the requested body. This model can be applied to many situations, such as preventing accidental repetition of posts on forum websites.

The above is what the concept and application of HTTP idempotence is. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.