State Management in Stateless Web Applications: Basics

The proliferation of REST and statelessness in Web Application and Web API design, state management often becomes a matter of misunderstandings and conflict in development teams. Programmers of back-end systems may be used to assume that session-related state is preserved server side and may be referred to as needed by the application code. However, stateful implementations may suffer from performance and scalability limitations, making thus the stateless approach a viable alternative, especially when high-load Web-based systems are considered.

How to pass data between requests in state-less / session-less Web applications

The problem here is that there are cases in state-less Web applications where data from an interaction may be required in subsequent interactions to be processed by the server, even though they are not stored in the server in some form. In this case, you will have to let the Web client provide these data as context (or state) of subsequent interactions.

Specifically, say for example that upon a form submission (Req1) you need to redirect the client (Resp1 (302) - Req2 -Resp2 (200)) to a second page/form where she should fill certain further information and submit (Req3). However, certain information submitted during Req1, or computed by the server as a result of Req1, need to be processed along with the information provided during Req3 so that the server can apply its processing logic. In this case, there are two basic options you can follow:

1. Cookies as context: I will not go into the theoretical aspects of how HTTP and REST considers state however, this is a case where Cookies can be used in a REST-compliant manner. More specifically, Resp1 should include Set-Cookie headers specifying appropriate cookies to be set by the browser. Subsequently, the browser includes the cookies to Req2 and ultimately to Req3 so that they can be processed by the server.
2. As part of the URL: The data that need to be passed to Req3 can be part of the redirection URL and subsequently to the Req3 URL. As URLs are primary elements of HTTP messages and are characterized by increased visibility (e.g. visible to the end user, logged into files/history, etc.), the information may need to be encoded or even encrypted before being included in the URL.

Presumably, there is a number of issues that should be considered when allowing the client to convey session-related state. For instance, trust between client and server is one of the most important ones. If the data that should be passed are sensitive, or should not be tampered by the client or any mediating component, then encryption techniques should be employed before passing the data to the client (either as Cookies or as part of the URLs).

Also, it should be understood that such a mechanism enforces an explicit dependency between the two pages, therefore the second page should not be able to be accessed without the provided cookie (i.e. the Req2 should fail if no Cookie has been specified).