« Functional wannabe | Main | Jon Udell meets metacrap »

Jabber and alternate REST architectures

Give it a REST. Nice piece from Joe Hildebrand on RESTful Jabber.

At the plumbing level, IM, Linda and P2P infrastructure can help realize the SOA integration dream, at least as much as HTTP. Unless that is, HTTP evolves - for example to include events (possible, we know how to), or allowing individuals to run servers (with probability approaching zero I think, but see mod-pubsub for an excellent compromise). Linda-like systems such as Javapaces are a personal favorite and represent a very interesting way to bootstrap workflow or events in a tiered system.

One difficulty is that HTTP is deployed everywhere. Thus altering or extending it is pushing against the mother of installed user bases, which is growing daily - 3 years ago a HTTP integration baseline was novel, next year it will be everyday. Also, there is a practical, rubber-hits-the-road aspect to using HTTP - in my experience integration architectures predicated on HTTP traffic tend to be welcomed by admins, ops and security auditors. Other protocols are liable to run into heavy resistance, and may require significant educational effort (or more plainly, the hard sell), perhaps enough to throw out schedules, and the risk to shipping isn't always justified. In fairness, these folks have to live with what you've built, protocol choices and all - but in these times wield they a peculiar moral authority, notably in the security area.

Nonetheless, I'm something of a REST bigot, and HTTP represents a good baseline choice for integrations spanning administrations and trading partners, especialy now that the webservices RPC view is withering somewhat. Which is not to say that alternate REST application protocols aren't welcome, HTTP can only be suitable for so many things, simply that there's a lot of work to be done to get even one such protocol widely deployed.

The optimal strategy today seems to be to gateway off HTTP onto a message queue, n-tiered or tuplespace, and where it make sense leverage HTTP headers to reduce the negative impact of tunneling one app protocol through another, while ensuring that application level resources are named with URIs and neither they nor the state transitions are hidden behind an MVC or Front Controller blackhole.

While many people want to know where the REST toolkit is at for the server side, more than anything we need to focus on REST clients. HTTP clients as the obvious example, have to become better web agents. Much better. It's absurd, that in 2004, browsers do not support PUT and DELETE, in large part because specs such as HTML, XHTML and XForms have been misguided enough to subset HTTP. This really does hurt anyone's ability to deploy RESTful systems and as a result is costing all concerned a fortune - I'd wager that the much of the architectural inanity, waste, and cost in web systems can be traced back to web clients. Right now, major application APIs in what Tim O'Reilly dubs the web operating system are working off an inadequate subset of HTTP's uniform interface (GET and POST). Client limitations are also I believe bleeding into RSS/Atom specs resulting in constraints. This needs to be driven out, and the same mistake avoided in future clients implementing alternate protocols predicated on REST.

January 4, 2004 04:06 AM


Trackback Pings

TrackBack URL for this entry:

Listed below are links to weblogs that reference Jabber and alternate REST architectures:

» RESTful Jabber from Stefan Tilkov's Random Stuff
Bill de hÓra points to a nice piece on REST+Jabber by Joe Hildebrand.... [Read More]

Tracked on January 4, 2004 02:44 PM