I'm reading Roy Fielding's dissertation Architectural Styles and the Design of Network-based Software Architectures, which introduces the REST architectural style.
Roy explains that cookies are a violation of REST as they introduce stateful behaviour – cached responses may no longer apply (for example, hitting the back button), and server-side statelessness is a constraint of REST.
There is no reason why the client should not maintain state however, this is perfectly acceptable.
So if I have a RESTful API – for an online store for example – and I want to persist user state client side for a long time – between multiple sessions, are there any alternatives to using cookies to persist local state in modern browsers?
If it matters, I assume I'm running a javascript app in the browser.
Are there any ways I can create client-side-only cookies?
This question is related a similar question about cookies for authentication in REST…
UPDATE:
…but in my case I am not concerned with authentication strategies – just in how to persist state between sessions without sending state to the server.
To give the discussion better context, when talking about cookie based authentication, Roy says:
cookie-based applications on the Web will never be reliable. The same functionality should have been accomplished via anonymous authentication and true client-side state.
Best Answer
There's HTML5 local storage, which allows you to keep data without it contaminating the HTTP requests you make. It's intended for pretty much exactly this use case: complex Javascript applications that want to store persistent information locally.
http://www.w3.org/TR/webstorage/
Note that REST doesn't mean banning all state from the server, sometimes you genuinely want to update things; especially in the "airline ticket" example you might want to explicitly create a "reservation" object before payment with a POST that returns a URL for the reservation. The client then hangs onto the URL, but the server-side object exists to prevent booking the same seat twice.