A little understanding of the stateless (stateless) in rest

Passing SessionID in a request is generally considered unrestful, and it is a very restful practice to include the user's credentials (authentication information, certificates) in each request. Such a problem is often plagued by problems. This paper discusses some concepts of rest, explains the state in rest architecture , stateless (stateless), and the difference between the two states.

This morning in Yahoo's mailing list, I saw a rather interesting discussion titled RESTful vs. Unrestful:session IDs and authentication (51CTO Editor's note: Meaning rest to non-rest,session ID and authentication). It is puzzling to the friends who started the discussion that why passing SessionID in a request is generally considered unrestful, and that it is a very restful practice to include the user's credentials in each request. Look at him. Following the understanding of the "statelessness" attribute in the rest architectural style, I find it necessary to make a brief collation of this often misunderstood vocabulary and related concepts, in the hope that this essay will explain what state is, why it is stateless, And the difference between the two states in the rest-style architecture, and finally I'll start with my understanding and answer the author's question.

First, the "state" of a Web application protocol usually refers to some kind of public information reserved for two interrelated user interactions, which are often used to store data such as workflow or user state information. This information can be specified in different scopes, such as page,request,session or global scopes, and the responsibility for storing them can also be the client side or server side. While the storage state provides many conveniences for enterprise software development, it also brings a number of limitations to other aspects of the distributed system, such as load balancing, in stateful mode, where a user's request must be committed to a server that holds its associated state information, otherwise these requests may not be understood , this means that the server side cannot freely dispatch user requests in this mode. Another issue related to this is fault tolerance, where the server that holds the user's information is down, and all recent interactions with that user will not be transparently transferred to the standby server unless the server synchronizes the status information of all users with the primary server at all times. Furthermore, since HTTP itself is not a stateful protocol , developers must implement the passivation and activation of States through simulations. Therefore, in order to overcome these shortcomings, the stateless (statelessness) architectural style attributes have received extensive attention.

Stateless means that any Web request must be completely isolated from other requests, and when requested, the request itself contains all the information required by the corresponding end for that request. The presence of this constraint improves the visibility, reliability, and scalability of the distributed system, and the specific introduction can refer to the thesis of Dr. Roy T. Fielding. These from the whole system point of view stateless seems to be too abstract, then for users, how to feel the state and the difference between stateless. The simple way is the browser's Back button, if a website expects the user to interact with the a->b->c process, and when the execution to the B-back, then the system is likely not to operate in the way it expects, because the user's state may be irreversible modification. Conversely, a search engine (I mean a search engine in the ordinary sense, rather than personalizing it based on the user's search history) is an example of a stateless architecture. Any user can enter http://www.google.com/search?q=RESTful&start=100 in the browser address bar to get a record of RESTful records starting with 100th, and when the Google Morocco server is paralyzed , the relevant user request is transparently transferred to the other server.

Everything seems to be clear, so what caused that friend's misunderstanding, the answer is that the restful architecture has two different interpretations of state: the status of the application and the state of the resource (Resource, Application). The application state refers to the state information associated with a particular request, while the resource state reflects a particular state of the server-side resource at a given moment, which is not changed by the user's request. Any user's request for that resource at the same time will get the performance of that State (representation). The restful architecture requires that the server side does not maintain any resources related to a particular HTTP request, so the application state must be provided by the requester during the request. Then go back to the question in that mailing list, why passing a session ID is a violation of the rest architecture style and passing user credentials is not. I think the author's doubts arise from his failure to distinguish between stateful and stateless schema attributes, and the belief that "passing on information of a certain state" to the server is a "stateful" performance. There is actually no correlation between state and stateless and the request itself, and it is important that the state information is stored by the requester or the responder. The session ID can be considered a key to identify a session state, and passing it to the server means a request: "Please take out this state message for me", that is, the request assumes that the response Fang Pao has status information. because the state associated with a particular request belongs to the application state, and the restful schema requires that any such state be provided by the requester, passing the session ID is considered a unrestful practice. In turn, user credential, as an application state, is expected to be provided by the requester, so passing the user credentials in the request (ignoring security issues) is consistent with the RESTful architecture specification.

This essay is more or less a kind of purist flavor, but I think some concepts are worth pondering. The emergence of any kind of architectural style has its expectations, the improvement of existing programmes or the expectation of overcoming problems. As rest, it is expected that the scalability of the component, the independent deployment of components, interface unification and other characteristics, and stateless as a feature of the implementation of this set of requirements, the individual think it is necessary to clearly understand and practical development process implementation.

Reference:

Http://developer.51cto.com/art/200906/129424.htm

A little understanding of the stateless (stateless) in rest