The reason, in my previous post, that my Audible link wasn’t a direct link to a search on Douglas Adams titles, is because of the downside of sessions.
This post will seem like child’s play for those of you already in the Web site programming business, but here goes:
You know the difference between dynamic and static content, right?
Static content means you receive exactly the Web page that’s on the server’s file system. The Web page never varies regardless of who asks for it.
Dynamic content means some or all of the information you see comes from other sources, usually big ol’ databases, and that information is used to construct the page right when you ask for it.
Examples of dynamic content include: a Yahoo! email account, Amazon.com, a dot-Mac account, etc.
Some of the most interesting kinds of dynamic content require you to have an account with the Web site, where it stores your identity, your preferences, your history, etc. on the server.
The idea of a session has to do with how they know that the you of the account is indeed the you requesting the Web page, from one page to the next. Unaided HTTP is stateless. If you request two pages in a row, the Web server doesn’t have any idea that the same person requested both.
There are at least two ways to make that connection. One involves storing information with the client (i.e. you). This is done with cookies that are sent to your browser and which your browser stores and makes available to the Web server. This way, the Web server doesn’t have remember anything special from page to page – it asks you who you are each time.
But this can lead to problems. What if you don’t have cookies turned on? What if you delete one of them? What if the information is particularly sensitive, like a credit card number, which you would rather not leave unprotected on the user’s computer?
A more robust solution, used by application servers like WebObjects and BroadVision, is to create a collection of information called a session on the server side the very first time a user shows up. The only thing the user has to tell the Web server each time she requests a page is the ID of that session.
That session information takes up space on the server, space that can add up for thousands of users, millions of users over time. Remember: stateless. Being a Web surfer means never having to say goodbye.
Application servers get around this by having sessions expire. If you haven’t asked for a new page within a certain time limit, then that session ID becomes invalid, its information thrown out, and if you ask for a page after that, you get the dreaded “Your session has expired” message.
Recap: (1) Session aren’t eternal. (2) Session IDs are needed to access the dynamic content of sites like Audible and Yahoo!. So I can’t give you a URL for Audible content, because I can’t give you an accompanying session ID that will be guaranteed to be valid by the time you want to use it.
So if you use WebObjects for your Web site, you can never give out static URLs? Well, not quite, but this post is long enough already, so I’ll talk about it next time.
Weaponized Fluff 
What I have yet to see on a public site is graceful session degradation. That is, let’s say you’re at store.apple.com and you’re looking at a new PowerMac. You email the link to your friend.
The next day, the friend visits the link. Obviously by now the session would have expired. However, encoded in the URL is enough information to at least bring up the referenced product page. Sure, the shopping cart and added goodies get blown away, but at least there’s some semblance of state.
More tricky is if the session was still active. But this comment is long enough already, so I’ll leave it for next time 😉