Sam says:
> I've been doing some reading on REST. I'm not convinced that REST
> dictates GET. Here are three quotes from Roy Fielding, the
> "inventor" of REST:
>
> REST is an architectural style -- it does not dictate protocol syntax.
> There's no basis for "everything must use GET" in Web architecture.
> there is a trade-off between GET and POST that usually involves the
> size of the parameter content.
>
> I'm now convinced that one can architect a system in accordance
> to the principles of REST and then implement that system using
> RPC style, HTTP transport, POST binding, SOAP.
http://radio.weblogs.com/0101679/2002/04/28.html#a414

I think that most REST fans would agree this far. You *could* architect
a system according to these principles. After all, SOAP is just a
syntax. But if the relevant specifications do not encourage or require
this, then you will have no interoperability with someone else who
happens also to have read Roy's thesis but, for instance, to have called
his "GET" method "fetch" and his "PUT" method "chuck." And furthermore,
the WAY you say "where to get from" and "where to put to" will be
non-standard: SOAP does not encourage nor require you to use URIs as
resource identifiers.

HTTP is a *standard* way of doing REST over the Internet. Now of course
we could reinvent REST-on-the-Internet in SOAP syntax two layers above
HTTP but it seems a little bit ridiculous to me. A better strategy is to
use SOAP as an extension to HTTP that adds the features HTTP lacks.

> ... In fact, I'll go
> further and state that the GoogleSearch is an instance of this.

I disagree. Here are the four principle ideas of REST:

1. identification of resources;

Google does not identify resources explicitly. I had to infer that every
method/parameter combination was a resource. Then I built a layer that
identified each of those URIs through the Web's addressing mode: URIs.

2. manipulation of resources through representations;

SOAP has no concept of either resources or representations and the
Google API certainly did not add them!

3. self-descriptive messages;

Okay, I'll concede this: SOAP may be ugly but its not quite binary!
Still on a scale of 1 to 10, the HTTP version wins! But more important,
the HTTP version is self-descriptive to *any HTTP intermediary*
including a cache or proxy. The SOAP version is self-descriptive only to
intermediaries trained to expect the particular method names.

4. and, hypermedia as the engine of application state

In order to shorten the article, I left out a couple of paragraphs with
examples of ways that Google *could* have used hypertext as the engine
of application state.

"For instance, imagine if the search API returned a URI to the cached
page, just as it does in the HTML version of Google. I could declare in
WRDL (as opposed to WSDL) that the cachedPage element of searchResult
resources points to a document of type text/html. I could also define a
resource type for Google "directory catalogs", then I could declare
strong types (XML namespaces or schemas) for the links from search
results to the directory catalogs and back. WRDL is designed (okay,
being designed) to mirror the structure of the Web, rather than impose a
component-oriented view on top of it."

It would be great to have bidirectional links from the Google XML
repository to the Open Directory XML repository! It would take much more
effort to do the thing with SOAP and it would not scale as well to
several directory services (with potentially varying APIs) and several
search engines (with potentially varying APIs).

I've documented the technical weaknesses of the Google solution. In
particular, nothing is addressable and that makes it incompatible with
any tool that can only work with addressable information. The ones I
happened to mention will probably elicit a yawn from the SOAP crowd
(XSLT -- so 1999) but the more important point is that any other web
service that wants to interoperate with Google will have to explicitly
hard-code those three methods instead of "just knowing" that a URI is
sufficient to get information out.

I didn't mention REST in the article because I think that we make more
progress when we approach from a concrete technical point of view. Plus,
I suspect Roy is getting sick of the REST hype.

Paul Prescod