If REST applications are supposed to be stateless, how do you manage sessions?

up vote50down votefavorite 20

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. Update: 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?? rest session-state share|improve this question edited Jun 24 '10 at 2:20 Jarrod Roberson 27.5k945102 asked Jun 23 '10 at 20:30 Zak  9,18352248

2   @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 1   @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 1   "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 add comment

5 Answers

activeoldestvotes

up vote27down vote

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 not be stored on the server, but passed around to everyone 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 an order of magnitude or more clients in a stateless fashion.