RE: SOAP breaks HTTP?

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

There is more than that -- does the POST actually go to the same URI?
Why do you POST against URI "y" to modify resource "x"?  If I can GET a
resource, and I own it, I should also be able to PUT it.  If GET is the
only thing that actually works RESTfully against the majority of URIs,
then I contend that we haven't really got REST yet.  My dream is that
every resource that supports GET can also support PUT, and can reliably
be part of triples that describe metadata about that resource
*independent* of the resource.

SOAP is about sending a message to an endpoint, with no semantics about
whether that message will invoke RPC, change the resource associated
with that endpoint, etc.

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

OK, I think you missed my point -- the point is that *most* sites do
things like assign temporary session keys to their users, and the
"resources" being represented are dependent on that "session" key.
Whatever token is embedded in the URL or cookie is used to determine
user context and manage the "sensitive" data on the other side.  All
access to resources is controlled through business logic and
user-specific context.  

This desire to avoid exposing resources through URIs is just one reason
that people design systems in a way that hides *functionality* behind
URIs rather than *resources*.  When I say that I like the ideas of REST,
I am talking about the cases where you actually expose *resources*
through URIs, and I want it to look like I described above.  I am just
pointing out that it is unreasonable to ignore the people (or their
reasons) who hide *functionality* behind URIs.  

And there *is* a difference -- please don't tell me that "exposing
functionality is just an example of REST, since the return value is a
representation of a transient state."  I think a "resource" needs to
meet a higher bar than just "you can do a GET on it", because then a
resource is not distinguishable from an RPC request.  And in fact, this
is why I think we have a problem today -- most people use GET and POST
with things like PHP, ASP, etc. as an RPC.  They tell themselves,
"everything I have done here with GET and POST I could just as easily do
with RPC".  Precious few people even bother to make their dynamic pages
addressable through bookmarks, let alone metadata.  And this is not even
talking about other ways that you *should* be able to use a "resource".

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

Well, for starters I think that (lack of) bidirectional symmetry is
horrible.  POST is not very RESTful anyway, IMO, and more systems should
support PUT.  Next, there is no good infrastructure in place for
referencing metadata about a particular URI.  Google ":link" search and
the bookmarks menu in your browser are the only ones that are common.
Just the lack of these two things, IMO, severely cripple the *value* of
URIs to the average person.  To the average person, GET and POST are the
only valuable uses of a URI, which encourages him to think of URI as an
RPC endpoint.  If people had some more valuable uses of URIs that
actually depended on the URI being a more reliable resource reference,
then maybe the problem would take care of itself (since users would
punish providers who failed to provide reliable, universal
addressability, and customers would reject products that did not provide
bidirectionality).

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

Well, it makes it less likely that people will use the GET querystring
overloading to pass RPC-like parameters.  In other words, I want to have
some degree of confidence that when I GET a resource, I can also PUT it
(given appropriate permissions).  If people stop overloading the
querystring with RPC parameters, I improve my chances.  Maybe there are
others...

> 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

Is it the stockQuote example that bothers you?  I have no strong opinion
about whether that should be a resource GET or an RPC call.  But the
point is, GET of a resource makes sense for some things, and in other
cases, developers will insist on hiding all of their resources behind an
endpoint that exposes *functionality*.  Maybe you can argue that some
places where a person uses RPC or Message-passing should really use GET.
But you cannot argue that *all* message-passing architectures should use
GET.  And users wouldn't listen anyway.

In other words, being able to pass a message to a URI and allowing the
URI to opaquely act upon that message *is* a legitimate use case.  You
cannot ignore this use case.

> example of a SOAP web service that uses URIs properly. Pointing to
flaws
> elsewhere is really not, in my opinion, relevant.

Well, can you point me to an example of a POST web service that uses
URIs properly?  Then take that example and just use SOAP as the envelope
when POSTing.  There are quite likely web services in production that
meet that criteria (although I dunno, since it depends on what you mean
by "uses URIs properly).

Received on Tuesday, 26 March 2002 16:15:05 UTC