HTTP, the Hypertext Transfer Protocol, has been designed under the constraints of the REST architectural style. One of the well-known constraints of this REpresen­tational State Transfer style is that communication must be stateless. Why was this particular constraint introduced? And who is in charge then of maintaining state, since it is clearly necessary for many Web applications? This post explains how statelessness works on today’s Web, explaining the difference between application state and resource state.

24 August 2012

Roy T. Fielding, the main author of the HTTP 1.1 specification, has devoted a whole chapter of his doctoral dissertation to the REST architectural style. REST forms the basis of HTTP, the protocol we use to browse the Web everyday. When Fielding derives the fundamental properties of REST, statelessness is chronologically listed as the second property, only preceded by client–server separation. It comes therefore as no surprise that statelessness is elementary to the success and growth of the World Wide Web.

Statelessness eliminates the need to remember

The notion of statelessness is defined from the perspective of the server. The constraint says that the server should not remember the state of the application. As a consequence, the client should send all information necessary for execution along with each request, because the server cannot reuse information from previous requests as it didn’t memorize them.

Concretely, this means if you’re browsing an image gallery and the server has just send you image number 23, your client cannot simply say next to the server. Instead, it asks for image 24 to advance in the gallery. Indeed, your client has to supply all information necessary to execute the request, since the server does not remember that you were viewing image 23.

The good thing is, you don’t have to know either that you were viewing this particular image. Because, along with the representation of this image, the server can send you links labeled “previous” and “next”, leading to the corresponding images. Isn’t that a contradiction? No, it’s not: at the time the server was generating the representation of image 23, the server was in the middle of processing your request, so it knew which image you requested and what the previous and next images were.

The concept of sending a representation of a resource along with the controls (such as links) that lead to next steps, is called hypermedia. Thanks to hypermedia, servers do not need to remember state. Furthermore, clients do not have to know beforehand what steps they can take, because all that information is contained inside the hypermedia representation.

Statelessness makes the Web scale

Fielding cites three important properties that are induced by statelessness:

visibility

Every request contains all context necessary to understand it. Therefore, looking at a single request is sufficient to visualize the interaction.

reliability

Since a request stands on its own, failure of one request does not influence others.

scalability

The server does not have to remember the application state, enabling it to serve more requests in a shorter amount of time.

Especially scalability has proven important: mankind has never created an interconnected network larger than the Web.

Clients handle application state, servers resource state

Perhaps you are wondering now why we have can state on the Web at all. Because, clearly, if you send a Tweet, something changes on the Twitter server. So there must be some form of server state. To understand this in the light of statelessness, it is vital to see that there are two kinds of state. There is application state, which is the kind of state we’ve talked about until here, and resource state, which is the kind of state servers do deal with.

Application state is information about where you are in the interaction. It is used during your session with an application. For example, the fact that you are viewing picture 23, or the fact that you are logged in on Twitter, are both application state. Changes to this state are possible by the controls in hypermedia representations. In the pictures case, they are links, and on Twitter, they are the tweet box and button.

Resource state is the kind of (semi-)permanent data a server stores, and lasts beyond the duration of a single session of interactions. An image that has been uploaded to the gallery and a tweet you have sent are examples of resource state. So, as you can see, although HTTP is a stateless protocol, you can still have long-term state on the server. However, the short-term state that is used during your interaction with the server is solely your client’s responsibility, and it has to send it within every request. This makes the web stateless and therefore scalable.