Web/HTTP 2019.01.20 08:41

Although REST is stateless, it has state transfer in its name. It's a little bit confusing to everyone.


When you open a web page in the browser, you will act as a service consumer and the www server will act as a service provider to serve you with a webpage. If it is a normal connection, the client and the server will both perform a handshake and initiate a session (called a TCP connection).

After that, based on the server's and client's behavior, the state will change to either ESTABLISHED, IDLE, TIMEOUT, etc. But in REST, we are using the HTTP protocol which is a stateless, meaning the server will not store any session information about the client. The client is responsible for sending all of the details required by the server to get serviced, meaning when we invoke the URIhttp://somedomain:8080/senthil/services/page1 from the server, it has enough details about the client to serve page1 fully.

State Transfer

Using the same example, when you open a web page using some URL to view an image file (RESOURCE) on the server,the www server will show you (the client) the image in some format i.e a REPRESENTATION of the RESOURCE (image file).

During this process, the constant resource state of the server (i.e. the state of the image file which is stored in the server database) will be represented to client in an understandable format i.e. application state of the client. So, the resource state will remain constant in respect to clients, and only the representation of the resource will change, which in turn would change the application state.

Finally, the representation of the resource (how the image is displayed to the client), which implicitly changes the state of both the server and the client is called REST.

source -


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. client is responsible for storing and handling all application state related information on client 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 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, its 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 client. Provide credentials with the request. Each request MUST stand alone and should not be affected by the previous conversation happened from the same client in past.

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 which 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.

Advantages of Statelessness

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

  1. 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.
  2. Being stateless makes REST APIs less complex – by removing all server-side state synchronization logic.
  3. A stateless API is also easy to cache as well. A 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.
  4. The server never loses track of “where” each client is in the application because the client sends all necessary information with each request.

source -

'Web > HTTP' 카테고리의 다른 글

REST  (0) 2019.01.20
apache - 파일 크기 제한을 초과함 $HTTPD  (0) 2013.09.09
http - compression  (0) 2013.06.27
http - cache(web cache)  (0) 2013.06.24
http - request, response header  (0) 2013.06.20
http - accept header field  (0) 2013.06.19
Posted by linuxism