RE: SOAP breaks HTTP?

> SOAP/HTTP binding when we can figure out how to do it in a way that
> respects both web architecture ("everything has a URI") and HTTP ("use
> GET to get").

To do that, we would have to all agree on what the web architecture
really is.  Despite your attempt to parenthetically sneak in a
definition above, I don't think you can claim that there is significant
agreement on "the one true web architecture".

Even the comment "everything has a URI" is quite divergent from practice
today.  I will be the first to say that everything *should* have a URI,
and I wish that we could encourage this flow of all information into a
universally addressable infospace, but I don't get the impression that
you really know what that means, in practical terms.  For example, the
expedia URI you pointed out is *not* an example of a REST-ful interface.
Of course, if you take the position that (parameters-in-URI == REST) and
(parameters-in-POST != REST), then you could say so, but that is totally
missing the point of REST.  In the example of the expedia URI, the
parameters are rather meaningless to the end user, and are used to
process some business logic on the back-end.  That URI is not
addressable in any other form than GET, and is essentially using GET as
an RPC mechanism.

In practice, here is how 99.98% of the world use GET+parameters and
POST:  GET is for passing parameters in the URL so people can bookmark
them, and for cases when the information embedded it the URL is not
sensitive.  POST is for cases when the information to be passed is
large, or when you don't want peeping toms to be able to see it by
looking over the user's shoulder.  And it doesn't matter how much you
try to twist the whole world's arm to put everything in the URI --
people will insist on being able to hide things.  

This is the common practice (with or without SOAP), and we all agree
that it is cause for concern.  Many news sites don't expose news stories
in a REST-ful way, so links break.  It is already next to impossible to
store metadata triples about the average corporate page, because the
URIs are unreliable and the page content can change completely depending
on opaque parameters passed in the URI.  It is this idea that
"everything has a URI, so it can be addressed, and commented upon" that
is wonderful, but suffering.  If you want to fix that problem, SOAP is
the least of your problems, and more likely an ally.  There are too many
other *real* reasons why users are deploying HTTP solutions that are not
REST-ful, and in my opinion, SOAP has nothing to do with that -- SOAP
will neither encourage nor discourage people from RESTful architectures.

Received on Tuesday, 26 March 2002 13:30:32 UTC