[Web-SIG] and now for something completely different!

Phillip J. Eby pje at telecommunity.com
Thu Aug 18 05:00:49 CEST 2005

At 10:33 PM 8/17/2005 -0400, michael bayer wrote:
>its usually not my experience either, and I have rarely written any kind 
>of app that uses sessions.  99% of everything I've done relies upon 
>browser state as well.  although despite my being there "when the web was 
>won" in 95, I am hesitant to call myself a RESTFUL developer...to me, REST 
>seems to be taking some common sense ideas and turning them into some kind 
>of rigid ideological crusade, which is just as bad as all the other 
>ideological crusades we "web winners" had to fight with IIS and active 
>server pages, EJB, UML, SOAP, etc.

I agree; I just find it useful to use the REST banner because before that 
word came around, there was nothing to call the approach.  I'm a pragmatic 
RESTee in that browsers don't do PUT and DELETE so POST is pretty much what 
we have to work with for human-usable applications today.

>a document editing system is also a good example of where objects need to 
>be persisted in two different scopes, i.e. a session-scope as well as a 
>permanent scope.   I dont really think a session has anything to do with a 
>"physical three-tiered model".   physically, it can be whereever you 
>want.  i just think its advantageous from a conceptual point of view.

I don't object to server-side objects that are session-specific; I object 
to the "bag of arbitrary objects" session interface, that is typically 
stored in a web tier or middle tier.  Those are two distinct sins that are 
usually coupled in what most people think of as "a session".  When I say I 
consider sessions harmful, it's specifically those two characteristics of 
the common meaning of the term.  I'm not saying that I think there's no 
such thing as a "session" in the sense of a browsing session.  Shopping 
carts would be pretty hard to do, for example, without session-specific 
server-side objects.  I just think that storing the shopping cart data in 
anything other than your application database is almost certainly a Very 
Bad Idea.

More information about the Web-SIG mailing list