Statelessness in REST API

In REST, statelessness refers to when the client is responsible for storing and handling the session-related information on its own side.

Statelessness is one of the 6 key architectural constraints of REST. It recommends making all the client-server interactions stateless. What it means is that the server will not store anything about the latest HTTP request the client made. It will treat every request as new.

Each HTTP request to a RESTful service must contain all the information needed to understand and process this request. This kind of statelessness makes it easier to scale, cache, and manage the service.

1. What is a Stateless REST API?

A stateless REST API adheres to the principle of statelessness as defined by the REST architectural style. Stateless REST APIs do not establish or maintain client sessions. Clients are responsible for providing all necessary information in each request, such as authentication tokens, credentials, or context data. The server does not store client-specific session data.

The application’s session state is therefore kept entirely on the client. The client is responsible for storing and handling the session-related information on its own side.

This also means that the client is responsible for sending any state information to the server whenever it is needed. There should not be any session affinity or sticky session between the client and the server.

Statelessness means that every HTTP request happens in complete isolation. When the client makes an HTTP request, it includes all information necessary for the server to fulfill the request.

The server never relies on information from previous requests from the client. If any such information is important then the client will send that as part of the current request.

To enable clients to access these stateless APIs, it is necessary that servers also include every piece of information that the client may need to create/maintain the state on its side.

To become stateless, do not store even the authentication/authorization details of the client. Provide authentication credentials with each request. Thus each request MUST be stand-alone and should not be affected by the previous conversation that happened with the same client in the past.

2. Application State vs Resource State

It is important to understand the between the application state and the resource state. Both are completely different things.

Application state is server-side data that servers store to identify incoming client requests, their previous interaction details, and current context information.

Resource state is the current state of a resource on a server at any point in time – and it has nothing to do with the interaction between client and server. It is what we get as a response from the server as the API response. We refer to it as resource representation.

REST statelessness means being free from the application state.

3. Advantages of Stateless APIs

Stateless APIs are often simpler to develop, test, and maintain because they do not require managing session state or tracking client interactions.

There are some very noticeable advantages of having REST APIs stateless.

  • Statelessness helps in scaling the APIs to millions of concurrent users by deploying it to multiple servers. Any server can handle any request because there is no session-related dependency.
  • Being stateless makes REST APIs less complex – by removing all server-side state synchronization logic.
  • A stateless API is also easy to cache as well. Specific software can decide whether or not to cache the result of an HTTP request just by looking at that one request. There’s no nagging uncertainty that the state from a previous request might affect the cacheability of this one. It improves the performance of applications.
  • The server never loses track of “where” each client is in the application because the client sends all necessary information with each request.

4. Summary

A stateless REST API helps in making each HTTP request independent of previous requests. This feature is essential for building distributed systems that can handle a large number of client interactions while maintaining high reliability and efficiency.

Happy Learning !!

Reference: Roy T. Fielding on Stateless


Notify of
Oldest Most Voted
Inline Feedbacks
View all comments

I find the explanation of “Application state” misleading.

Another explanation of application state vs resource state can be found In RESTful Web APIs (Richardson and Amundsen. O’reilly) p. 13:

Application state is kept on the client, but the server can manipulate it by sending representations – HTML documents, in this case – that describe the possible state transitions. Resource state is kept on the serve, but the client can manipulate it by sending the server representation – an HTML form submission, in this case – describing the new state.


let’s assume that our application provides an admin dashboard in which the admin can access and see a list of connected users.In this case how can we get the list knowing that the server doesn’t store any info about the user session ?

med nizar

The solution that came to my mind, is to have ‘isLoggedIn’ attribute in the user class, and when the user hits logout, we can set isLoggedIn = false.
By doing so, we can retrieve connected users from DB by selecting users where isloggedIn = true.
The problem is that we are hitting the database in every login/logout request, is there any better solution for this ?


Regarding statelessness, almost all rest APIs use HTTP as a transport protocol, but HTTP itself uses TCP under the hood(while TCP is a stateful protocol). Kidly help me clear my confusion.


Thanks for your reply, kindly clear my last confusion. If rest server doesn’t store any information the how come it remembers our username and password when we send a request with base64 encoded username:password, also in token authentication, the server sends us a token based on the credentials that are stored at the server.


I understand now that even the client must send its credentials (with Basic Auth) every time with a new request, but does it violate the stateless operation as the server is still remembering the username:password in its database?


Username and password are not application state, they are just credentials. An example of state related to authentication would be if your application has an idea of a “session”. A good way to determine whether authentication is making your API stateful is whether you have “login” and “logout” endpoints. If these endpoints exist then your application is stateful.

Harpreet Kaur

If username/password is not considered application state then what all is considered application state


Not really, a typical login request on the server side will issue a response that tells the browser to set cookies on the client side, whereas a logout endpoint will issue a response that instructs the browser to clear those cookies, therefore the state is kept and managed on the client side, the server is not storing any state just issuing instructions to the client.

Mohammed Amine

Before every REST API call, an Authorization request should be sent to allow you to accomplish the REST API call. so the Authorization request is an independent request from your original REST API request.

Ken Ingram

Thank You. This cleared up some logical confusion I was having around the push for statelessness.
This explained that it is contextual.


It’s vey good information about stateless REST API. IS it poossible that REST API is stateFull and Can you also compare with SOAP…..
And also can you give real time example where statefull integration is required and REST API is not usefull …..

Anurag Malik

NO, Rest APIs are always stateless, server will not store any information and it rely always on client.