Leshek wrote:
That is a very good point Marc is making. The way I think about it, that
REST is not really stateless :-) it requires state separation:
application state - always on the client (what page is the client on);
can use cookies fully client controlled
resource state - on the server (no cookies)
That's a good point. And I'll add that server RAM is still a good place
for caching expensive resources, which is another typical use of the
Servlet session.
In my case, I'm building a Facebook app. When I recognize a user I give
them a cookie with their userid and some other application state
information encrypted in the value. I then use that encrypted value as a
key to a HashMap full of my own session objects.
If the session object goes away, that's fine; I can decrypt the cookie
and re-fetch the Facebook friend info. But in the normal case, I don't
have to decrypt anything, and I can give quick responses to interactive
users. And to my mind it's reasonable RESTful, which keeps the
architecture clean.
William
