Security methods and idempotent of HTTP

recently in the study of HTTP, see the security method of HTTP and idempotent part, not quite understand, especially "POST method is non-idempotent" do not understand, into the search information, found the following two valuable articles, special turn around. Understanding the power of HTTPTransferred from: http://www.cnblogs.com/weidagang2046/archive/2011/06/04/2063696.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 Web APIs are 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) T He 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. As shown in Figure 1:

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. As shown in Figure 2:

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. The post and put are defined in the HTTP specification: The POST method is used to request the origin server accept the entity enclosed in the Reque St 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 that the enclosed entity is 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. Summary

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

safe operation, idempotent operation

transferred from: http://blog.sina.com.cn/s/blog_4fd9844201010j0b.html

Google has some Chinese information, basic understanding of idempotent is how to go. Please forget it.
The put,delete operation is idempotent. Idempotent means that the results are the same regardless of the number of operations performed. For example, I use put to modify an article, and then do the same operation, after each operation the result is not different, delete is the same. By the way, because the get operation is safe, it is naturally idempotent.


The post operation is neither secure nor idempotent, such as a common post repeat loading problem: when we make the same post request several times, the result is that we have created a number of resources.


The significance of security and power is that when the operation does not reach the desired target, we can retry without any side effects on the resource. In this sense, the post operation is often harmful, but many times we still have to use it.


Another thing to note is that the create operation can use post, or put, except that the post is acting on a collection resource (/articles), and the put operation is on a specific resource (/articles/123), and then, in a more popular sense, If the URL can be determined on the client, then use put, if it is determined on the server, then use post, for example, many resources use the database self-increment primary key as identity information, and the identity information of the created resource is what can only be provided by the server, this time must use post.


One of the characteristics of a idempotent operation is that its arbitrary multiple executions have the same effect as one execution. Idempotent operations are "friendly" to proxies and caches, because additional execution of idempotent operations does not have a detrimental effect on both (except bandwidth waste).
The Put method is idempotent, and idempotent means that for a successful execution of a request, no matter how many times it executes, the result is consistent. That is, if you want, you can use the Put method to update the hotel resources any time, the results are the same. If two put methods occur at the same time, only one of them will win the final victory and determine the final state of the resource. The delete operation is also idempotent, if a put method and the Delete method occur at the same time, then the resource is either updated or deleted, and cannot be stuck in an intermediate state.


If you are not sure whether the put or delete is executed successfully, and you do not get the status code 409 (CONFLICT) or 417 (expectation Failed), then do it again. Instead of requiring additional reliability protocols to avoid duplicate requests, there is usually no effect on duplicate requests.


The above description does not apply to the Post method, because the Post method is not idempotent, and to perform the same post request two times it is important to pay attention. The idempotent that is missing from the Post method explains why the browser always pops up a warning every time you resend the POST request. The Post method is used to create the resource without requiring the client to specify the instance ID


Idempotent functions, or idempotent methods, are functions that can be executed repeatedly with the same parameters and can obtain the same result. These functions do not affect the state of the system, and do not worry that repeated execution will cause changes to the system. For example, the "GetUserName ()" function is a idempotent function, and the "DeleteFile ()" function is not. Idempotent is an important concept in HTTP session and EJB failure transfer.
What to do when a method call is in progress. The answer is: the processing is aborted and the client sees an error message prompt (unless the method is idempotent). Only if the method is idempotent, some load balancers can attempt to fail over the methods to other instances.


Idempotent why is so important. Because the client does not know when the server will fail (when the method is just starting to call or when it is almost finished). If the non-idempotent method, the two calls will change the system state two times, the system will be in an inconsistent state.


In complex applications, it is unlikely that all of the methods will be turned into idempotent methods. As a result, errors can only be reduced through failover, and it is not possible to fundamentally avoid them.


The application is designed to be idempotent: an idempotent means that a manipulation does not modify state information, and returns the same results each time (in other words: the same effect is done multiple times and once), typically, Web requests, especially HTML forms Are sent multiple times (when the user clicks send button two times, reloading the page multiple times), resulting in multiple HTTP requests. The design servlet and other Web objects are idempotent and can tolerate multiple requests. Refer to the design mode "Synchronized Token" and "idempotent Receiver" for details on how to design idempotent applications.