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.
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:
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??