« Faults of Omission (aka the Frame Problem) | Main | The best ways I've found for implementing constructors... »


Episode IV: A New Hope.

Some of my colleagues and I have also been concerned about the tight coupling between the transport protocol (HTTP) and the MVC-type framework that many implementations such as Struts exhibit today. Ganesh Prasad on TSS

HTTP is not a transport protocol, it's an application protocol. This isn't just a nitpick - such protocols clearly mandate behaviour for client and server applications (hence the name) in a way that transport protocols do not. Let's stop this damaging meme.

When you do it right, there's nothing overly wrong with having your web app tied to HTTP. By design HTTP provides what you need for workflow, actions, representation and state. We can think of HTTP defining a protocol for applications based on a state machine. You move from one state to the next by following a link. The client's job is to request state transitions, the server's job is to react to those to state transitions and return representations of the next state. Layered over this is a fixed set of actions for state jumps (get, post, put, delete, etc) and an extensible header metadata format (content-length, pragma, etc) for understanding the state repesentations.

The problem is that we don't, generally speaking, do it right - we keep trying to treat web apps like desktop apps and keep trying to pretend the network is not there. We don't explictly name each state as URLs, we bury that information in session cookies and behind front controller dispatching mechanisms. We don't declare our actions properly, we casually invent new ones and tunnel everything through form posts. If we insist on abstracting HTTP away for web apps, we end up reinventing HTTP in our applications, which (imo) invariably leads to new frameworks that abstract out common functionality. This abstraction through reinvention seems to be the case with WebWork2 and Java Server Faces; it is already a significant issue with webservices, where a primary purpose of treating HTTP as a transport is to get arbitrary and possibly dangerous invocations through firewalls (aka protocol tunnelling).

But the key insight behind frameworks such as WARS and Mission Control (note: my employer's product) is right - MVC as interpreted by most webapp frameworks is the problem, not the solution. The problem is that as the framework moves further away from the underlying application protocol it ends up reinventing with what's already available in the protocol, except now the reinvention is private to the implementation framework. That's guaranteed to occur when people start treating HTTP or SMTP as being conceptually and architecturally the same as TCP or UDP (which is why I honed in on Ganesh's comment).

HTTP by being a REST-oriented protocol, has most of the architectural properties that N. Alex Rupp wants, so it's good to see him mention the REST thesis as an influence. Where HTTP does fall down (or more accurately, where browsers fall down) is session management. I think the answer to this is to place the session state under a URL space distinct from the web application space the client is accessing. That way both the server and client (or any authorized third party) can refer to it in way that doesn't induce the security problems posed by cookies.

[Update: Stefan Tilkov followed up with some related links ]

January 31, 2004 05:06 PM


Trackback Pings

TrackBack URL for this entry:

Listed below are links to weblogs that reference REST WARS:

» REST and MVC from Stefan Tilkov's Random Stuff
A very good article by Bill de hOra: REST Wars.... [Read More]

Tracked on January 31, 2004 08:57 PM

» Related Entries from Stefan Tilkov's Random Stuff
You might have noticed that my weblog now display related entries for most of the posts. In case you are wondering why these sometimes don't seem to make sense, the explanation is that they are generated automatically. (In case you're interested how, h... [Read More]

Tracked on February 6, 2004 04:13 PM