Take the 2-minute tour ×

I'm in need of some clarification. I've been reading about REST, and building RESTful applications. According to wikipedia, REST itself is defined to be Representational State Transfer. I therefore don't understand all this stateless gobbledeygook that everyone keeps spewing.

From wikipedia:

At any particular time, a client can either be in transition between application states or "at rest". A client in a rest state is able to interact with its user, but creates no load and consumes no per-client storage on the set of servers or on the network.

Are they just saying don't use session/application level data store???

I get that one goal of REST is to make URI access consistent and available, for instance, instead of hiding paging requests inside posts, making the page number of a request a part of the GET URI. Makes sense to me. But it seems like it is just going overboard saying that no per client data (session data) should ever be stored server side.

What if I had a queue of messages, and my user wanted to read the messages, but as he read them, wanted to block certain senders messages coming through for the duration of his session? Wouldn't it make sense to store this in a place on the server side, and have the server only send messages (or message ID's) that were not blocked by the user?

Do I really have to send the entire list of message senders to block each time I request the new message list? The message list pertinent to me wouldn't/shouldn't even be a publicly available resource in the first place..

Again, just trying to understand this. Someone please clarify.


I have found a stack overflow question that has an answer that doesn't quite get me all the way there: http://stackoverflow.com/questions/2641901/how-to-manage-state-in-rest which says that the client state that is important should all be transferred on every request.... Ugg.. seems like a lot of overhead... Is this right??

share|improve this question
@S.Lott: I don't think it's intentionally misleading. I think it is a misunderstanding because of confusing terminology. –  JUST MY correct OPINION Jun 24 '10 at 3:23
@JUST MY correct OPINION: Interesting guess. I could not believe such a thing, myself, since it is obvious from that "stateless" means the REST protocol itself is stateless; which says nothing about the underlying application state and updating it with PUT, POST and DELETE requests. –  S.Lott Jun 24 '10 at 10:18
@S.Lott : The HTTP protocol itself is stateless. From what we've discussed below, REST is a viewpoint of how to build your app while not having the webserver handle session state (as opposed to other kinds of state in things like the DB). I didn't even think REST was a protocol, but rather a view on how to use the HTTP protocol. I thought you guys cleared it up that it was about how to build your application to scale by having the client side store all client specific session data, and making URI accesses as idempotent as possible, except where they shouldn't be. Maybe not... :( –  Zak Jun 24 '10 at 18:35
"Maybe not.." What does that mean? Do you have a new question? Feel free to search SO for it. If it doesn't exist here, then ask it. –  S.Lott Jun 24 '10 at 23:16

9 Answers 9

By stateless it means that the web server does not store any state about the client.

That does not preclude other services that the web server talks to from maintain state about business objects, just not about the clients connection state.

The clients state should never be stored on the server, but passed around to every place that needs it.

That is where the ST in REST comes from, State Transfer. You transfer the state around instead of having the server store it. This is the only way to scale to millions of users.

The load of session management is amortized across all the clients, the clients store their session state and the servers can service many orders of magnitude or more clients in a stateless fashion.

share|improve this answer
@Zak: Because millions of sessions is millions of sessions. The point is to avoid the overhead of all this session management. –  S.Lott Jun 23 '10 at 20:45
it is not boldness it is experience –  Jarrod Roberson Jun 24 '10 at 2:18
Thanks. That's a nice, clear explanation. –  Dogweather Jun 8 '13 at 2:01
It seems like for an application that you only expect to have, say, 10,000 concurrent users it would be more efficient to use sessions though. 10,000 sessions shouldn't be an issue for one server, and that way you avoid the necessity for database access (user validation) with every request. Shouldn't you move to full REST when your application requires it? –  CorayThan Jul 27 '13 at 20:12
Nothing in my answer implies a solution based on database access on every request, if you think it does, it is a failing on your part to understand authentication and authorization at that scale. The authentication can be implicit in the state, do you think that facebook does a "database access" on every request of its REST API? Or Google for that matter? hint: no –  Jarrod Roberson May 31 at 15:56

Statelessness means that every HTTP request happens in complete isolation. When the client makes an HTTP request, it includes all information neccessary 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. Statelessness also brings new features. It’s easier to distribute a stateless application across load-balanced servers. A stateless application is also easy to cache.

There are actually two kinds of state. Application State that lives on the client and Resource State that lives on the server.


Resource state is the same for every client, and its proper place is on the server. When you upload a picture to a server, you create a new resource: the new picture has its own URI and can be the target of future requests. You can fetch, modify, and delete this resource through HTTP.

Hope this helps differentiate what statelessness and various states mean.

share|improve this answer


No. They aren't saying that in a trivial way.

They're saying do not define a "session". Don't login. Don't logout. Provide credentials with the request. Each request stands alone.

You still have data stores. You still have authentication and authorization. You just don't waste time establishing sessions and maintaining session state.

The point is that each request (a) stands completely alone and (b) can be trivially farmed out to a giant parallel server farm without any actual work. Apache or Squid can pass RESTful requests around blindly and successfully.


If the user wants a filter, then simply provide the filter on each request.

Wouldn't it make sense to ... have the server only send messages (or message ID's) that were not blocked by the user?

Yes. Provide the filter in the RESTful URI request.


Yes. How big can this "list of message senders to block" be? A short list of PK's?

A GET request can be very large. If necessary, you can try a POST request even though it sounds like a kind of query.

share|improve this answer
It seems this violates the lazy programmer principle. Why keep sending the same state over and over if you can just do it once? It seems like you will have to do all authentication over again each time, as well as all role lookup, filter setup, etc... –  Zak Jun 23 '10 at 20:54
BTW, thank you for the answer. It seems like I'm hearing, "because that is what we have found works well in practice." And that is always a very good reason :) –  Zak Jun 23 '10 at 21:01
@Zak: I have no idea what "lazy programming" is. Sending things "over again each time" is simpler -- do the same thing -- no weird cache management or server affinity or anything. It is simpler to have each request totally stand in it's own. And -- as a lazy programmer -- I prefer that. Just process the request and be done with it. –  S.Lott Jun 24 '10 at 0:34
looking up something over and over is way more expensive than having it given to you when you need it. Plain and simple Database systems and especially RDBMS systems will ALWAYS be the bottleneck in a web based application. It is less complicated, and less code, and less code means less bugs, and less bugs means less maintenance, and that means less money to support the system. If don't believe us go implement a system that has 12 million concurrent users and get back to us on how your server side session management for 12 million current users works out. –  Jarrod Roberson Jun 24 '10 at 2:18
@JarrodRoberson - I don't understand you comment: "looking up something over and over is way more expensive...". Isn't that exactly what is happening by providing credentials everytime? The server needs to authenticate the user upon each request - ie: query the DB, validate credentials and retrieve the user privileges. I realize that a good L2 cache can mitigate the query against the DB itself, but is that not more effort than being able to retrieve the state from a simple session? –  Eric B. Feb 14 at 4:27

You are absolutely right, supporting completely stateless interactions with the server does put an additional burden on the client. However, if you consider scaling an application, the computation power of the clients is directly proportional to the number of clients. Therefore scaling to high numbers of clients is much more feasible.

As soon as you put a tiny bit of responsibility on the server to manage some information related to a specific client's interactions, that burden can quickly grow to consume the server.

It's a trade off.

share|improve this answer
plus1 good point –  zencv Nov 6 at 14:08

Historical view of user application state management

Sessions in the traditional sense keep the user's state in the application inside the server. This may be the current page in a flow or what has been previously entered but not persisted to the main database yet.

The reason for this need was the lack of standards on the client side to effectively maintain the state without making client specific (i.e. browser specific) applications or plug-ins.

HTML5 and XML Header Request has over time standardized the notion of storing complex data including application state in standard way on the client (i.e. browser) side without resorting to going back and forth between the server.

General usage of REST services

REST services are generally called when there is a transaction that needs to be performed or if it needs to retrieve data.

REST services are meant to be called by the client-side application and not the end user directly.


For any request to the server, part of the request should contain the authorization token. How it is implemented is application specific, but in general is either a BASIC or CERTIFICATE form of authentication.

Form based authentication is not used by REST services. However, as noted above REST services are not meant to be called by the user, but by the application. The application needs to manage getting the authentication token. In my case I used cookies with JASPIC with OAuth 2.0 to connect to Google for authentication and simple HTTP Authentication for automated testing. I also used HTTP Header authentication via JASPIC for local testing as well (though the same approach can be performed in SiteMinder)

As per those examples, the authentication is managed on the client side (though SiteMinder or Google would store the authentication session on their end), there's nothing that can be done about that state, but it is not part of the REST service application.

Retrieval requests

Retrieval requests in REST are GET operations where a specific resource is requested and is cacheable. There is no need for server sessions because the request has everything it would need to retrieve the data: authentication and the URI.

Transaction scripts

As noted above, the client-side application itself calls the REST services along with the authentication that it manages on the client side as well.

What this means for REST services [if done correctly] is to take a single request to the REST server will contain everything that is needed for a single user operation that does everything that is needed in a single transaction, a Transaction Script is what the pattern is called.

This is done through a POST request usually, but others such as PUT can also be used.

A lot of contrived examples of REST (I myself did this) tried to follow as much of what has been defined in the HTTP protocol, after going through that I decided to be more pragmatic and left it to GET and POST only. The POST method does not even have to implement the POST-REDIRECT-GET pattern.

Regardless though, as I had noted above, the client-side application will be the one calling the service and it will only call the POST request with all the data when it needs to (not every time). This prevents constant requests to the server.


Though REST can be used for polling as well, I won't recommend it unless you have to use it because of browser compatibility. For that I would use WebSockets which I had designed an API contract for as well. Another alternative for older browsers is CometD.

share|improve this answer

Stateless means the state of the service doesn’t persist between subsequent requests and response. Each request carries its own user credentials and is individually authenticated. But in stateful each request is known from any prior request. All stateful requests are session-oriented i.e. each request need to know and retain changes made in previous requests.

Banking application is an example of stateful application. Where user first login then make transaction and logs out. If after logout user will try to make the transaction, he will not be able to do so.

Yes, http protocol is essentially a stateless protocol but to make it stateful we make us of HTTP cookies. So, is SOAP by default. But it can be make stateful likewise, depends upon framework you are using.

HTTP is stateless but still we can maintain session in our java application by using different session tracking mechanism.

Yes, We can also maintain session in webservice whether it is REST or SOAP. It can be implemented by using any third party library or you can implement by our own.

Taken from http://gopaldas.org/webservices/soap/webservice-is-stateful-or-stateless-rest-soap

share|improve this answer

Have a look at this presentation.


According to this pattern - create transient restful resources to manage state if and when really needed. Avoid explicit sessions.

share|improve this answer

The whole concept is different... You don't need to manage sessions if you are trying to implement RESTFul protocol. In that case it is better to do authentication procedure on every request (whereas there is an extra cost to it in terms of performance - hashing password would be a good example. not a big deal...). If you use sessions - how can you distribute load across multiple servers? I bet RESTFul protocol is meant to eliminate sessions whatsoever - you don't really need them... That's why it is called "stateless". Sessions are only required when you cannot store anything other than Cookie on a client side after a reqest has been made (take old, non Javascript/HTML5-supporting browser as an example). In case of "full-featured" RESTFul client it is usually safe to store base64(login:password) on a client side (in memory) until the applictation is still loaded - the application is used to access to the only host and the cookie cannot be compromised by the third party scripts...

I would stronly recommend to disable cookie authentication for RESTFul sevices... check out Basic/Digest Auth - that should be enough for RESTFul based services.

share|improve this answer

You have to manage client session on the client side. This means that you have to send authentication data with every request, and you probably, but not necessary have an in-memory cache on the server, which pairs auth data to user information like identity, permissions, etc...

This REST statelessness constraint is very important. Without applying this constraint, your server side application won't scale well, because maintaining every single client session will be its Achilles' heel.

share|improve this answer

Your Answer


