News You Can Bruise for 2007 June 12

(1) Tue Jun 12 2007 13:40: I was planning not to write about REST on my weblog for a while, especially since all this week I'm writing about REST on the JavaRanch forum, but Jon Udell pointed me to a comment by Paul H. on Jon's weblog that throws down the REST gauntlet. The context is our assertion in RWS that web applications and web services should work on the same principles. I'm just going to quote the general flow of the comment:

[T]he authors' goal is stated as being one "to reunite the programmable web with the human web" ... The unstated assertion here then is that in order to meet the authors' stated goals, the majority of today's Web Applications will need to be re-architected and re-written in order to conform to a RESTful style! ... [T]he RESTful approach is essentially unproven outside of the read-only Web... doesn't this run counter to the often-voiced argument that REST builds upon what makes the web what it is today?

First off I want to say that my goal of uniting the programmable web with the human web is the lofty, inspirational kind of goal, not the kind that gets a budget and a schedule. "Dream" might have been a better word. But yes, it goes both ways: web applications should be more RESTful, and web services should be more weblike.

Now, on to the critique of web services vs. the web. My quick answer comes from Sam's and my InfoQ interview. Again, I'm just quoting the general flow:

InfoQ: Another argument often brought up is that the standard claim that REST's advantages have been proven by the Web's success is actually a wrong conclusion — the reason being that most of the Web's usage is actually non-RESTful.
LR: There's some truth to this. Earlier I said that most websites don't expose write operations RESTfully. But I think removing the non-RESTful parts of the Web would make the Web better, and wouldn't hurt its success—except in the same second-order way it would hurt the Web's success if web browsers were stricter about invalid HTML... I decided there were three important reasons [for the Web's success]: everything has an address, pages link to each other, and you can manipulate the web using only a web browser.
The first two correspond to important features of RESTful web services: addressability of resources by URI, and hypermedia-as-engine-of-application-state... Rather than promoting REST by pointing to the Web as a whole, I would point to the incredible usefulness of URIs and links, two features largely ignored by WS-*.

Longer answer. First, by number of requests the read-only web is most of the web. Even if REST only made sense for read-only web services, the success of the read-only web and the tools built around it would justify a (short) book.

Second, the read-only web is not just GET. It's also URIs, media types, links, and application forms. That's most of the web technologies, and they're used on the web as they are in RESTful web services. All that's missing are write operations and resource forms. Fittingly, there's significantly more controversy about these: see GET/POST vs. GET/POST/PUT/DELETE and do-we-need-WADL. In the interview I ask whether "architectures consciously designed with REST in mind will 'win' over architectures that are simple but only intermittently RESTful." Those other architectures are today's web application architectures.

How big is the gap between web applications and RESTful services? Well, here's a RESTful rule for web applications: POST to the same URI you GET. The URI designates an object, not an operation, and we have a special way of distinguishing between safe (GET) and unsafe (POST) operations on objects.

I don't think that all web applications should be rewritten to follow this rule, because in general I'm opposed to doing work. But when I write web applications in the future I'm certainly going to hew to that rule. It's a cleaner design. Even if you think that rule is a waste of time, you probably don't think following it will break the web—and following it makes a web application resource-oriented and RESTful.

It's true that the success of the web doesn't reflect success on every aspect of RESTful web services, but the overlap is pretty large, and the web's success certainly doesn't stem from any systematic repudiation of RESTful principles.