My goodness, there’s certainly a lot of REST talk these days. I’m partly responsible; Paul Krill and I had a long talk at OSCON and he chose to pull out my dissing WS-* for his title: Sun technologist: SOAP stack a ‘failure’. This led to an incredibly long discussion thread on Yahoo Groups’ (irritatingly-named) “service-orientated-architecture” forum. Damien Katz was another provocateur, firing off REST, I just don't get it and “The web is built on REST. Therefore REST is good” Bullshit. This provoked Dare Obsanjo to a burst of restrained pedagogy in Explaining REST to Damien Katz. Let me stir this pot with a few questions, some vaguely heretical in flavor.

Has REST Been Fortunate in its Enemies?

I have been among the most vocal of those sneering at WS-*, and I’m comfortable with what I’ve said. But that doesn’t prove that the core WS-* ideas are wrong. Here are some of the handicaps WS-* struggled under:

• Lousy foundational technologies (XSD and WSDL).

• A Microsoft/IBM-driven process that was cripplingly product-linked and political.

• Designers undereducated in the realities of the Web as it is.

• Unnecessary detours into Architecture Astronautics.

As a result, we should be really careful about drawing lessons from the failure of WS-*. Specifically:

• Just because the XSD type system is malformed, you can’t conclude that the notion of schema-driven mapping between program data types and representation payloads is harmful.

• Just because WSDL is a crock, you can’t conclude that exposing a machine-readable contract for a service is a necessarily bad idea.

• Just because UDDI never took off, you can’t conclude that service registries are dumb.

• Just because SOAP has a damaging MustUnderstand facility and grew a lot of ancillary specification hair, you can’t conclude that some sort of re-usable payload wrapper is necessarily a dead-end path.

• Just because the WS-* security specifications are overengineered and based on a shaky canonicalization spec, you can’t conclude that message-level security and signing aren’t sometimes real important.

And so on. I personally tend to think that schema-driven mapping is hopeless, contracts are interesting, registries are a fantasy, and payload wrappers are very promising. But I don’t think that the history of WS-* is a very good argument for any of those positions.

Is Getting HTTP Right Good Enough?

REST, say its aficionados, is more than just HTTP. And that’s true in theory. But in practice, there are a whole lot of benefits to just getting HTTP right. Suppose just hypothetically that your app violated a bunch of REST precepts, say by making heavy use of cookies and never embedding hyperlinks in what it sent. But suppose also that it was a really good HTTP citizen; getting the caching right, not misusing POST, and taking advantage of idempotency where possible. Well, you know, it might be a pretty good app, and scale startlingly well.

The reason that this scenario feels a little strained is that who’ve come to understand HTTP have usually picked up some of the rest of the REST canon along the way, and put it to use.

That granted, I think the benefits from getting HTTP right are really really big; enough that they’re worth pursuing even if you don’t care to join any four-letter religions. And if you’re trying to explain to management why you’re working on sweating the HTTP details, just tell ’em you’re doing REST and you’ve got buzzword cover.

What Does “Hypermedia as the Engine of Application State” Mean, Really?

I’ll be honest: I’m not sure. On the other hand, one of the great advantages of being resource-centric, as in giving everything you care about a URI, is that whatever kind of messages you’re shipping around the network, URIs are easy to pack into them. And experience to date suggests that doing this leads to good results.

Is Statelessness Required?

It’s really easy to understand why, in an ideal-world network application, if none of the client implementations contain state, the scalability payoff can be huge. In the perfect REST world, state lives in resources, resource identifiers, and the representations you pump around the net.

Well, yeah, but in this world, that’s hard. For example, one of the places state shouldn’t live is in cookies jammed down clients’ throats. It says so right here in Roy’s thesis.

But damn, they’re useful. My intuition is that the architectural flaws are small enough, and the convenience-function benefits large enough, that they’re with us for the long haul.

And I think there’s a lesson here: that statelessness, like many other good things (Buddha-nature, purely descriptive markup) is an Aristotelian virtue; unattainable in an absolute sense, but rewarded to the extent you can practice it.

Is Being Message-Centric Good Enough?

The Web is attractive and thought-provoking because it succeeded in scaling to meet the needs of a global heterogeneous network where many had failed before, most notably CORBA and DCOM. The most obvious differentiator is that those other network programming frameworks tried to extend the notions of API and Object Model across the network. The Web doesn’t do APIs or Object Models; it’s just a set of protocols, agreements regarding the exchange of short series of messages, and what has to be in those messages.

My single most deeply-held conviction about network computing is that attempts to abstract away the underlying message traffic are in the long run doomed. So hmmm, maybe is it not only good enough to do HTTP right, maybe all you need is to face up to the fact that it’s all about message interchange, and proceed from there (of course, you’ll probably end up inventing something essentially like HTTP).

Are PUT and DELETE Essential?

During the design of AtomPub, a few people, including me, worried out loud about the use of PUT and DELETE in the protocol, simply because those functions aren’t supported in browsers, hence also not in servers, and are not available at all to programmers on the dumber class of mobile devices.

We were shouted down by the purists, who said that PUT and DELETE are essential features of the architecture. And they had good arguments, especially around idempotency and ETags for safe concurrent update. But you know, unlike most other REST conversations, those are arguments from theory not practice. I’m pretty convinced that AtomPub would work about as well if you overloaded the U and D in CRUD on POST, carefully and respectfully.

Having said that, I’m beginning to believe that the theoretical benefits of PUT will work out pretty well in practice, and I’m glad that AtomPub now gives PUT something useful to do.

Is “Do Like the Web” a Good Argument?

A common argument from REST proponents is “The Web works pretty well, so shouldn’t you be taking Web Architecture seriously as you go about your engineering?” For a recent example, see my comment on Damien Katz’s piece linked above.

While Damien is unconvinced, I think it’s actually a pretty good argument. I’ve never talked to Roy about this, but my perception is that REST was reverse-engineered from his understanding of what makes the Web work, based on having been there when some of the most important pieces were being built. And judging by my experience of getting Web stuff to work, Roy’s understanding is pretty much on the mark.

Anyhow, all the other strong REST arguments are theoretical. There’s a lot to like, on engineering-aesthetics grounds, about decentralized flat identifier namespaces, about the notion of Resource and Representation, about statelessness, about hypermedia, and so on. But all my favorite engineers are most impressed by arguments from practice not theory: “See, like that.”

Where Are the Tools?

I’m on record as thinking there’s not much out there. Let me be specific on what I mean by tooling: facilities for use by programmers that do away with redundancies and irritants and boilerplate; that let you do things faster and better.

Once you get past ActiveResource, Restlet, and Jersey, I’m not aware of much (but I bet there’ll be some shout-outs in the comments). Seems like an opportunity to me because, you know, REST really actually truly works, as religions go it’s a very practical one.