It happens again. Over at ebpml.org, JJ Dubray has a couple of related posts about the dark side of REST, and a proof that REST creates strong-coupling. I am not sure what to make of his style of writing, but like good citizen, let me try to make some sense here.
Let me start with his first point about the dark side of REST. A good chunk of his discussion is around SimpleDB, and how the REST community reacted. To quote him,
That was enough to wake up the inquisition lead by the grand priests of REST who were absolutely outraged at Amazon's latest heresy. Bill de Hora, Stefan Tilkov, Assaf Arkin, Subbu ... were all ready to burn the heretic who had committed one of the worst crime in REST history. Funny, how mechanical their reaction is: never discuss the questions always point at what not to do and occasionally what to do. There is never a single inconsistency in a religion -by definition.
Quite the contrary. The discussions were about correctly designing a REST interface. Why care about correctly designing it? So that an interface designed for consumption over HTTP can really take advantage of HTTP. Period.
It does not stop here. To quote Dubray again,
Unfortunately, he wanted you to come to the conclusion (insidiously) that "all action interfaces" are bad (Nice try Subbu).
I think he makes this statement in response to my post Why Bad REST is Easy?. He completely missed the point. Action interfaces are not bad! Having worked with a number of REST-wannabe applications, the common pattern I notice is that developers tend to translate their action-oriented interfaces into REST, which leads to poor REST APIs that fail to take advantage of what HTTP has to offer. Each problem domain requires a different approach towards solutions.
He then goes on to prove that REST does not care about versioning.
It has been notorious that REST is really bad at versioning (I am preparing an article on this topic that will be published early January). Of course the RESTifarian say that there is absolutely no need for versioning since there is only ONE interface (GET, PUT, POST, DELETE) and actions don't exist.
I think his comments are based on the belief that XSD and WSDL provide a versionable contract, and since RESTful applications do not require neither XSD nor a WSDL-equivalent, REST applications do not care for versioning. This kind of FUD is quite unfortunate.
No matter how an interface is described, remote interfaces ought to worry about forwards and backwards compatibility. Versionable XSD and WSDLs are one way to describe compatibility, but versioning an interface does not provide for backwards and forwards compatibility automatically. It is the responsibility of the producer of the application to accommodate for compatibility independent of XSD and WSDL, i.e., you have to code for compatibility. In fact, some of the best compatible systems don't have formal descriptions.
That brings me to the need for descriptions. Remote interfaces need to have descriptions so that we can understand the syntax and semantics, and can develop client applications that work. While SOAP world chose XSD and WSDL for descriptions of their interfaces, in the REST world, the descriptions are URIs, HTTP verbs, and request/response encodings. For instance, take a look at Amazon's description of a GET request to get a list of all the buckets from S3. To make such a description compatible, all it takes is to follow some simple guidelines, such as (a) keep minor additions into inputs optional, (b) never remove required parts of data from responses, and (c) follow the must ignore rule. See also Extending and Versioning Languages: Strategies for more discussion along similar lines. These rules apply independently of whether you are describing your data as XML, or JSON, or some other format. These rules seem hard when you try the first time, but over time, they become natural design principles.
Upon showing the dark sides of REST as above, Dubray moves on to prove that REST introduces strong coupling between producers and consumers. The proof is long in English, but I think his proof is based on the belief that RESTful applications don't have descriptions, which is quite appalling. As I just showed the Amazon S3 example, RESTful applications do have descriptions. Even this blog has a description - the description is hyperlinks and HTTP verbs, which my user-agent and my web server understand and support.