Re: SOAP breaks HTTP?

Joshua Allen wrote:
> 
> > 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".

The closest thing we have is this:

 * http://www.w3.org/DesignIssues/Overview.html

Plus there is broad agreement on the idea that URIs are the core of the
Web.

> 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.  

I wouldn't say that parameters-in-URI == REST and parameters-in-POST !=
REST. Rather I would say that using GET for GET and POST for POST is
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.  

What does that have to do with anything? REST (as described in the
thesis) says nothing about interpretation of URIs by end-users!

> ... That URI is not
> addressable in any other form than GET, and is essentially using GET as
> an RPC mechanism.

It uses GET for GET. That's REST. It uses a URI to address an itinerary.
That's REST. There is no RPC involved.

When I go to that page, it allows me to also submit information. It uses
POST. That's REST. The only mild transgression against REST is the use
of cookies but given the state of the art in browsers I think that that
is understandable (and probably wouldn't be necessary in a web service).
It isn't perfectly RESTful but it is very far along the path, much
farther than any SOAP-RPC service I've seen or can imagine.

> 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.  

Wonderful. That's exactly what GET is for.

> ... 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.  

In many, many circumstances, POST is used for non-idempotent operations,
as it is supposed to be. Using POST to do a GET is actually quite rare
in my experience. When you send "peeping tom" information like a
password it is almost always logically a *POST* because you are sending
information that you want the server to remember for you.

> ... 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.

For the types of things where we have to choose SOAP-RPC versus REST,
there will be no "URL bar" and the "peeping toms" will be intermediaries
that can snoop on the body as easily as the URL.

> 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.  

No argument here. We need to improve education and re-evaluate what in
the infrastructure is leading people awry.

> .... If you want to fix that problem, SOAP is
> the least of your problems, and more likely an ally.  

How so?

> ... 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.

SOAP demonstrably discourages people from RESTful architectures in that
a SOAP (e.g.) getStockQuote is NOT REST-ful and one cannot do a REST-ful
GET of a STOCK QUOTE without abandoning SOAP. I'm still waiting for an
example of a SOAP web service that uses URIs properly. Pointing to flaws
elsewhere is really not, in my opinion, relevant. 

We're back to: "people abuse the web therefore we should have a
standardized way of abusing the web." I would really appreciate a
response of the form: "Here's how I built a SOAP web service that uses
the Web infrastructure according to Tim's 5-year old axioms." Double
points if it is not just a SOAP service but a SOAP/RPC service.

 Paul Prescod

Received on Tuesday, 26 March 2002 14:24:18 UTC