Putting some concerns to REST?
Charles Miller is concerned about URLs in Seaside and similar frameworks:
In the oft-cited Smalltalk continuation framework Seaside and its Ruby port Borges, all links are anonymous callbacks, and thus are meaningless, transient strings bunged on the end of the application's base URL.He's basing these comments at least in part on this post of mine:As a random example, take web stores. I can copy an Amazon URL from my location bar, paste it to a friend in e-mail or an IM, and that friend will see exactly the same product that I'm looking at. Whenever I go to a site, find something I want someone else to look at, paste them the URL and discover they've encountered a "This is not your session" message, I make a strong mental note to avoid that site in the future.
People often complain about having "meaningless" numbers in the URLs, but they enable a level of abstraction over HTTP that wouldn't otherwise be possible.Let me be more explicit. To enable the abstraction I'm talking about, you absolutely do need the meaningless numbers in the URL, and people do complain about this because it makes the URLs "ugly". But Charles was assuming my statement was also implying something that it actually isn't: that you can't have meaningful segments in the URL. That's not true in Seaside.
The way it works is this. At any point in a Seaside program, you can specify additional path elements that you wish to appear in the URL. These will get inserted in front of the session key, so that instead of
/seaside/myapp/@dbdDSmNVWJwEFCWv/MdvDvfXzyou get, say,
/seaside/myapp/exec/obidos/ASIN/1904151043/@dbdDSmNVWJwEFCWv/MdvDvfXz.It doesn't matter how long this extra information is because the special /@ string identifies where the session key starts.
Now, as long as that session key is valid, the extra segments will be ignored: they provide a rough pointer to the current position in the app, but the session and continuation IDs provide a more exact position, so they will be used instead. However, if you send the link to a friend1, or bookmark it and come back once the session has expired, your application will get a chance to look at the meaningful part of the URL and construct a new session that starts at the appropriate point. This is extra work - Seaside doesn't force you to do it if your users don't need it - but it's explicitly supported in the framework for those that do.
Once place you can see this in action is at www.tric.nl, which uses a Seaside-based Wiki written by Cees de Groot. To prove my point, I've used a deep link to the Smalltalk page.
1Out of the box, Seaside doesn't protect you from "session hijacking" if you send a link to someone else - if you want to let someone else in on your session, feel free. Depending on the nature of the app, and the method you use for authentication, this may be fine. However, if this was something you needed, it would be very easy to add a cookie or IP based check that ignored the session key section of the URL if the session wasn't created on that computer.
Comments
Persistent URLs
[Lukas Renggli] March 17, 2004 2:28:06.308
In Scheme there is a special registration mechanism for URLs that are persistent longer than the current session. They use it to send around URLs as part of the confirmation of a registration-process. I think it would be cool to have something like this is Seaside too, so we could write:
| member | member := self registerMemberWizard. self sendMailTo: member confirmationUrl: self showWelcomeMessage: member; showLoginDialog: member asPersistentSessionURL self showSentConfirmationMail.OK
[Vincent D Murphy] March 17, 2004 11:49:29.140
I'm glad to hear you say this because I shared Charles' concern, but didn't feel knowledgable enough about continuation-based web frameworks to voice it. However, I still have a reservation with what you say about using a session key. Why not use the HTTP headers for session keys? I still think that opaque string has no place in a URI. Thanks for the clarification anyway, I will probably give contination-based frameworks a closer look because of it.