"Some Web frameworks use session state to track and hold information about the user throughout their journey through the site, however they go against the RESTful principles and should really be treated as a bug."<p>I'll bet this guy's not fun to be in design meetings with.
How do you prevent against CSRF attacks (<a href="http://en.wikipedia.org/wiki/Cross-site_request_forgery" rel="nofollow">http://en.wikipedia.org/wiki/Cross-site_request_forgery</a>) if you don't maintain any state server-side?<p>The classic (and best) method for foiling these attacks is to store a special/randomized token in a server-side session, and require that token to be submitted from the client via a standard form, essentially making forged attacks impossible. Take away the ability to store these tokens in some sort of server-side session, and you open your site to attack?
I read this and thought - why not just use sessions?<p>His client example is riddled with security and integrity issues. People don't like accidentally closing a tab and losing everything.<p>His server example is just another way of doing sessions.
Old, old, old idea. Even I was writing about this in 2006.<p><a href="http://www.jgc.org/blog/2006/04/stateless-web-pages-with-hashes.html" rel="nofollow">http://www.jgc.org/blog/2006/04/stateless-web-pages-with-has...</a><p>When I wrote that Matt Sergeant posted that this idea had been around since at least 1999.
What if you need state for users without username and password?<p>For instance let them add things to their cart and only require registraton/login once they buy.<p>What if you want more than one basket?<p>What if baskets are shared among users.<p>Replace "basket" with "state" for above.<p>How is <a href="http://example.org/shop/users/johndoe/basket" rel="nofollow">http://example.org/shop/users/johndoe/basket</a> different/better than <a href="http://example.org/shop/users/johndoe/?sessionkey=123456" rel="nofollow">http://example.org/shop/users/johndoe/?sessionkey=123456</a> or <a href="http://example.org/shop/baskets/123456/" rel="nofollow">http://example.org/shop/baskets/123456/</a><p>"differ from storing the cart in a user session" I never store anything but sessions in user sessions, carts go in the cart table/whatever. Carts may have a session_id they are associated with, but they are probably keyed to user instead(depends). Probably stored in a cookie(state on the client).<p>Not saying author is wrong, I just don't get it.<p>And how come rest folks don't end their resources with a '/'. like <a href="http://example.com/users/bob/" rel="nofollow">http://example.com/users/bob/</a> The "root" resource ends in a slash. <a href="http://example.com/" rel="nofollow">http://example.com/</a> Having that be inconsistent with other resources always bugs me. I tend to have verbs not end in slash. <a href="http://example.com/users/bob/delete" rel="nofollow">http://example.com/users/bob/delete</a> Very consistent and orderly to my obcom mind.
I'm in full agreement with him within the frames of the shopping cart analogy/function. I'm trying to think though, of things I currently use a session state for that would suffer under this process.<p>The cart on client scares me when it has to do with data that isn't trivial. (ie, personal data etc) I don't have these concerns with the "cart on the server" idea, but it does create some interesting issues where devs need to be explicitly aware of who is accessing this data at any given time.
an interesting read but one thing I didn't understand, how is one meant to save the plaintext username & password client side (so as to be able to send them with each request) without putting them in a cookie or requiring that the user's browser is set to 'remember this password' - anyone got any ideas?