Linking to SOAP-exposed resources

Since the REST/RPC/SOAP discussion flared up again, I've been
looking for a single clear statement about what kind of problem may
exist, and what to do about it. I found it in Paul Prescod's
Google's
Gaffe:

The point that has not yet filtered through to the mainstream of
web services implementors is that linking is just as important for
machine-to-machine applications as it is for human-facing
applications. If it is impossible to link to SOAP-exposed
resources, then they are less powerful and useful than HTTP-exposed
ones. Until SOAP has an addressing mechanism as rich as HTTP URIs,
SOAP is less, rather than more powerful than HTTP.

A hugely important class of web services is
addressable by URI, and accessible to GET. We call these things web
pages. The fact that such pages can be consumed by human-operated
browsers and machine-operated scripts in the same way was, and
remains, a great thing. As some pages evolve into services intended
mainly for programmatic use, XML becomes a natural representation
format. This need not undermine the value of the URL-line which, as
I've
pointed
out, remains an incredibly vital style of access.

In practice, though, I don't find that SOAP undermines the
URL-line. Toolkits seem perfectly happy to let me turn service
names, method names, and parameters into URLs. I have here, for
example, both Visual Studio.NET and GLUE. If I write a SOAP service
called StockQuote in either of these, with a method called
getQuote, then in addition to the SOAP/RPC interface I can
automatically use:

http://host/StockQuote/getQuote?sym=VRSN

or:

http://host/StockQuote.asmx/getQuote?sym=VRSN

Should Google have done something like this? Absolutely. I miss
being able to type
http://google.com/xml?q=roy+fielding.
As I pointed out in a essay on
monetizing
web services, this was possible a few months ago. Arguably it
still should be. But that's just a business decision Google has
made. In practice, given the restrictions placed on the Google API,
the regular web-friendly HTTP GET remains the preferred way to link
to the infinite space of Google queries, as people do every
day.

So, SOAP toolkits already support a RESTful mode for GET-style
(though not for POST-style) operations. Since GET-style reads are
what both people and machines mainly use the Web to do, I'd say
we're in pretty good shape.

PS: The top Google result for "restful soap" -- ahead of a bunch
of W3C mailing list postings -- is an ad for
a restful soap full of aromatic fragrance.The name
of this restful soap?
Desert Storm. Go figure.