Understanding statelessness

The statelessness constraint helps services to be more scalable and reliable. Statelessness, in the REST context, means that all the client requests to the server carry all the information as explicit (stated), so that the server understands the requests, treats them as independent, and those client requests keep the server independent of any stored contexts. Keeping the session state within the client is important to manage this constraint in the services.

The following diagram shows the Service Consumer (client) and the Service States are independent and managed within the client and server respectively:

The statelessness constraint imposes significant restrictions on the kind of communications allowed between services and consumers, to achieves its design goals. The following are the restrictions to achieve statelessness:

• It is the complete responsibility of the client to store and handle all the application states and the related information on the client side.
• The client is responsible for sending any state information to the server whenever it's needed.
• No session stickiness or session affinity on the server for the calling request (client).
• The server also needs to include any necessary information that the client may need to create a state on its side.
• HTTP interactions involve two kinds of states, application state and resource state, and statelessness applies to both. Let's see how the statelessness constraint is handled in each state:
  • Application state: The data that is stored on the server side and helps to identify the incoming client request, using the previous interaction details with current context information
  • Resource state: This is referred to as a resource representation, and it is independent of the client (the client doesn't need to know this state unless it is available as response is needed), and this is the current state of the server at any given point in time