title: If REST applications are supposed to be stateless, how do you manage sessions?
body: <p>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 <em>Representational State Transfer</em>. I therefore don't understand all this stateless <em>gobbledeygook</em> that everyone keeps spewing.</p>
  <p>From wikipedia:</p>
  <blockquote>
  <p>At any particular time, a client can either be in transition between
  application states or &quot;at rest&quot;. 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.</p>
  </blockquote>
  <p>Are they just saying don't use session/application level data store???</p>
  <p>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 <em>no per client data</em> (session data) should ever be stored server side.</p>
  <p>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?</p>
  <p>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..</p>
  <p>Again, just trying to understand this. Someone <em>please</em> clarify.</p>
  <hr />
  <p><strong>Update:</strong></p>
  <p>I have found a stack overflow question that has an answer that doesn't quite get me all the way there:
  <a href="https://stackoverflow.com/questions/2641901/how-to-manage-state-in-rest">How to manage state in REST</a>
  which says that the client state that is important <em>should</em> all be transferred on every request.... Ugg.. seems like a lot of overhead... Is this right??</p>