Understanding the power of HTTP

From http://www.cnblogs.com/weidagang2046/archive/2011/06/04/idempotence.html

The HTTP protocol-based Web API is one of the most popular distributed service delivery methods nowadays. Whether it's in large-scale Internet applications or enterprise architectures, we've seen an increasing number of SOA or restful web APIs. Why are Web APIs so popular? I think it owes a lot to the simple and effective HTTP protocol. HTTP protocol is a kind of distributed resource-oriented network application layer protocol, whether it is server-side to provide Web services, or client consumer Web services are very simple. Coupled with the development of browsers, Javascript, AJAX, JSON, and HTML5 technologies and tools, the design of the Internet application architecture shows from the traditional PHP, JSP, ASP. NET and other server-side dynamic Web pages to the Web API + RIA (Rich Internet applications) the trend of transition. The Web API focuses on providing business services, and RIA focuses on user interface and interaction design, and the division of labor in two areas is clearer. In this trend, Web API design will be a required course for server-side programmers. However, just as the simple Java language does not imply high-quality Java programs, the simple HTTP protocol does not imply high-quality web APIs. To design a high-quality web API, you need to understand the characteristics of distributed systems and HTTP protocols in depth.

Idempotent definition

In this paper, it is an important nature of the HTTP protocol to discuss: Idempotent (idempotence). The definition of idempotent in the http/1.1 specification is:

Methods can also has 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.

From the definition point of view, the power of the HTTP method is that one and multiple requests for a resource should have the same side effects. Idempotent is a semantic category, just as the compiler can only help check for syntax errors, and the HTTP specification does not have the means to define it by means of syntax such as message format, which may be one of the reasons why it is less valued. But in fact, idempotent is a very important concept in the design of distributed system, and the distributed nature of HTTP also determines its important position in HTTP.

Distributed Transaction vs Power design

Why do we need idempotent? Let's start with an example, assuming that there is a remote API that takes money from the account (which can be HTTP or not), we'll use the class function for a moment as follows:

bool withdraw(account_id, amount)

The semantics of the withdraw is to deduct amount amount from the account_id account, and if the deduction succeeds returns true, the account balance is reduced amount, and if the deduction fails, the account balance is not changed. 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 handled by the server side, but the server-side return result is lost due to network, etc., which causes the client to be unable to know the processing result. If it is on the Web page, some inappropriate design may make the user think that the last operation failed, and then refresh the page, which led to the withdraw was called two times, the account was also deducted one more money. 1 is shown below:

Figure 1

The solution to this problem is to use distributed transactions to ensure transactional withdraw functionality by introducing middleware that supports distributed transactions. 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.

Another, more lightweight solution is idempotent design. We can turn withdraw into idempotent by some techniques, such as:

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

The semantics of Create_ticket is to obtain a server-side generated unique processing number ticket_id, which will be used to identify subsequent operations. The difference between Idempotent_withdraw and withdraw is that a ticket_id is associated, a ticket_id represents an operation that is processed at most once, and each call returns the result of the first invocation. In this way, the Idempotent_withdraw is idempotent, and the client can safely call it multiple times.

A complete money-fetching process in a power-based solution 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, but in this design, its impact on the state of the system can be ignored, plus Idempotent_withdraw is idempotent, so any step due to network and other reasons such as failure or timeout, the client can retry until the results are obtained. 2 is shown below:

Figure 2

Compared to distributed transactions, power design has the advantage of being lightweight, easy to adapt to heterogeneous environments, and performance and usability. In some applications where performance requirements are high, idempotent design is often the only option.

The idempotent nature of HTTP

The HTTP protocol itself is a resource-oriented application layer protocol, but 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 provisions of the HTTP protocol; the other is SOA, Instead of using HTTP as an application-level protocol, it takes the HTTP protocol as the Transport Layer protocol, and then builds its own application-layer protocol over HTTP. The HTTP idempotent discussed in this article is mainly for restful style, but as seen in the previous section, Idempotent is not a specific protocol, it is a characteristic of distributed system, so both SOA and RESTful Web API design should consider idempotent. The semantics and idempotent of HTTP GET, DELETE, PUT, post four main methods are described below.

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.

It is easy to confuse HTTP post and put. The difference between post and put is easy to think of as "post means creating resources, put means updating resources"; in fact, both can be used to create resources, the more essential difference is idempotent. This is defined in the HTTP specification for post and put:

The POST method is used to request 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 have been created on the origin server, the response should is 201 (created) and contain an entity which DESC Ribes the status of the request and refers to the new resource, and a location header.

The PUT method requests 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 a existing resource, and that URI is capable of being defined as a new resource by T He requesting the user agent, the origin server can create the resource with that URI.

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.

After introducing the semantics and idempotent of several operations, let's look at how to implement the above mentioned withdrawal function in the form of Web API. Very simple, with post/tickets to achieve create_ticket, with put/accounts/account_id/ticket_id?amount=xxx to achieve idempotent_withdraw. It is important to note that strictly speaking the amount parameter should not be part of the URI, the true URI should be/accounts/account_id/ticket_id, and amount should be placed in the body of the request. This mode can be applied to many occasions, such as: forum website to prevent accidental repetition of posts.

Summarize

This paper briefly introduces the concept of Idempotent, the method of replacing distributed transaction with idempotent design, and the semantic and idempotent characteristics of HTTP main methods. In fact, if you want to trace the trace, idempotent is a concept in mathematics, the expression is the n-th transformation and 1 times the same result of the transformation, interested readers can learn from Wikipedia.

Reference

RFC 2616, hypertext Transfer Protocol--http/1.1, Method definitions
The importance of Idempotence
Stackoverflow-put vs POST in REST

Understanding the power of HTTP