REST misunderstandings
08-Sep-05
My apologies if you’ve been looking for this and found it 404; my hosting provider had a uncharacteristic data-loss, and the backups were incomplete. -jsled, 2005-10-06
It’s really unfortunate that the REST community has mis-represented REST so thoroughly.
Mark Baker points to an excellent example, and I offer another: Amazon Web Services talking about SOAP vs. REST.
It’s quite unfortunate when one of the largest “REST-interface” providers doesn’t really understand what it means…
The key issues I have here are the following:
- ignorance of the de facto REST-architecture technology.
- ignorance of the de facto SOAP-technology architecture.
- ignorance of REST’s extensibility model.
- ignorance that REST has an even-better-defined-processing-model than SOAP, by definition.
But the real issue here is that the REST camp has seemingly embraced RPC-invocation-over-HTTP as “REST”.
Ignorance of the de facto REST-architecture technology.
The AWS piece seems to imply that HTTP is not the standard technological implemntation of REST. C’mon.
Ignorance of the de facto SOAP-technology architecture.
Most SOAP interfaces published on the web are there to support a RPC architecture. Both the “REST” and SOAP AWS interfaces are exceedingly RPC interfaces.
Ignorance of REST’s extensibility model.
Certainly the ability for a transport protocol to negotiate a representation, as well as the architecture’s explicit enumeration of a representation’s media-type and encoding lead to a much more interesting extensibility model than SOAP, but that may be a topic for another article.
Ignorance that REST has an even-better-defined-processing-model than SOAP, by definition.
This is the one that really makes me believe that the AWS team — and, in fact, the majority of people out there — mis-understand REST.
“The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components [...]” — REST, emphasis mine
SOAP is primarily a mechanism by which to invoke arbitrary functions on a remote host. WSDL — perhaps the most closely-related SOAP technology — serves to describe these functions.
Purely, there is a strict subset of the use of SOAP whereby the functions are not arbitrary, and are in fact agreed-to before hand. For instance, we might agree to the function-set “GET”, “QUERY”, “SUBSCRIBE”, and “SUBMIT-FORM”. Or maybe “GET”, “POST” or even “GET”, “PUT”, “POST”, “DELETE”. Perhaps “SEND”, “RECEIVE”. But the central feature here is that we have a uniform interface between components.
In any case, it’s basically incorrect that SOAP and REST are basically the same thing. It’s also misleading to say that REST is basically an “introductory” SOAP. They’re just really different things, and to indicate otherwise is to not understand the difference.
The REST community, however, should have been making that difference quite clear for a while, now.