Is it possible (for webapps, that is)? Is it desirable? Current practice is to set up a session on the server side, then use the cookie (or a GET parameter or URL substring) as a key to associate individual HTTP requests with sessions.
There are some alternatives to cookies and URL rewriting — and even to server-side sessions themselves — that will work under many conditions:
- With HTTP authentication, the browser will resend credentials for each page, at the cost of a bit of extra HTTP overhead (the first time a page is viewed, there will be an extra exchange with the server, at least for Firefox). The user id can make an effective session key, and, in the case of authentication alone, can eliminate the need for sessions altogether.
- For multi-stage, choreographed processes, using a separate URL for each stage — in the best spirit of REST — eliminates the need to track the user’s progress as part of the session information, and also makes it easier for the user to bookmark a step halfway through the process and return to it later.
- It is also possible to stash temporary information in POST parameters: though some toolkits might balk, it is possible to have both GET and POST parameters to the same POST request, where the POST parameters won’t mess up the URL (though they will cause browser complaints with page reloading).
None of these is a perfect substitute for sessions, but I wonder if we haven’t used sessions and session variables a bit too much, just because toolkits have made them so easy to use. There’s also the philosophical problem that using any extra-URL technique (cookies, HTTP authentication, etc.) to customize a page violates the REST principle that n requests with the same URL should return the same object.
Who reading this has implemented a reasonably-complex webapp without using cookies or URL rewriting? What about a webapp that doesn’t use sessions at all?