1. Statelessness
As per the REST (REpresentational “State” Transfer) architecture, the server does not store any state about the client session on the server-side. This restriction is called Statelessness.
Each request from the client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.
Session state is therefore kept entirely on the client. The client is responsible for storing and handling all application state-related information on its own side.
It 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 sessions on 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 that request.
The server never relies on information from previous requests. If that information was important, the client would have sent it again in this request.
To enable clients to access these stateless APIs, it is necessary that servers also should include every piece of information that the client may need to create the state on its side.
For becoming stateless, do not store even authentication/authorization details of the client. Provide credentials with the request.
Each request MUST stand alone and should not be affected by the previous conversation that happened with the same client in past.
2. Application State vs Resource State
Please do not confuse between application state and 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 of time – and it has nothing to do with the interaction between client and server. It is what you get as a response from the server as API response. You refer to it as resource representation.
REST statelessness means being free on application state.
3. Advantages of Statelessness
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 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.
Reference: Roy T. Fielding on Stateless
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.
REST does not talk about underlying protocols. It refers to includes all information necessary for the server to fulfill a given request
REST does not talk about protocols. It refers to includes all information necessary for the server to fulfill a given request and should not take advantage of any stored context on the server.
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:passwordin 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.
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.
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 …..
NO, Rest APIs are always stateless, server will not store any information and it rely always on client.