There's a massive amount of er, what did you say, "dry theory and voluntary speak" on the question of sessions and continuations vis-a-vis REST. Unashamed, I'll add more.
The rub here is adherence to Fielding's "Stateless" constraint (5.1.3: "each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.") This is a good thing for the underlying architecture of the WWW, but a largely irrelevant thing to higher level application design. Keep state all you want and where you want, if it's appropriate to your problem domain. Yet there it is; the seminal document defining REST says, in a big booming voice, *** REST Is Stateless ***. In a framework called "Restlet" is there any way to encompass the establishment of server-side state without incensing the peanut gallery? It's not my baby, I can't say. But I'd guess No, unless somebody brings in a written excuse from Dr. Fielding. > Given the above, I think the 'resourced' way of keeping some > (admittedly) application flavoured state up at the server would be to > create temporary 'resources' that allow to store some use-case related > state. The transient resource behavior you describe is neatly done at a layer below Restlet. We, for example, keep resources in a virtual, versioned filesystem (VFS) that uses WebDAV semantics; a "transient" property combined with an expiring lock provide the information needed to manage and reap transient resources. This isn't glued to Restlet especially well yet (it's a general Java facility that predates our Restlet experience), but it's why we're working on getting a full set of RFC 2518 semantics into Restlet and making a proper Client connector for our VFS. We plan to share it as commercial open source when it's ready. "REST" won't be part of the name, so Fielding's legion of zombies doesn't carry torches to our door. :-) - Rob
