Re: SOAP & REST

On Tue, 5 Feb 2002, Mark Baker wrote:

> > What I _think_ one would typically do with HTTP independent of SOAP would
> > be something like sending a GET to:
> >
> >         http://numbers.com/multiply?inputnumber1="3"+inputnumber2="4"
>
> That would be a good example of a URI that I would use, but what's
> important here is what information you can extract from the URI itself.
> More below.

Hum I don't think that the URI has any meaning. It may have one because
you can understand english, but that's just luck :), the only important
thing is that you will act on a resource, and give it some parameters
(untyped).
More than that, you can imagine that this "multiply" resource is giving
only the result as text/plain using HTTP, but it can be a more generic
resource that may export content (views) by HTTP or by other means.
The HTTP view, more precisely the HTTP-GET view correspond to only one
facet of the real resource.
A "thermic sensor" resource may export a nifty HTML page via HTTP or a
temperature report via email, and be the same resource.

> > implying that all the products represent one parameterized resource. Now,
> > consider the following SOAP:
> >
> >         <s:envelope xmlns:s="...soap env uri...">
> >                 <s:body>
> >                         <multiply xmlns="...math namespace...">
> >                                 <inputnumber1>3</inputnumber1>
> >                                 <inputnumber2>4</inputnumbe2>
> >                         </multiply>
> >                 </s:body>
> >         </s:envelope>
> >
> > An obvious binding would be:
> >
> >
> > http://numbers.com/?operation="multiply"+inputnumber1="3"+inputnumber2="4"
>
> Right.  The difference between this URI (and its SOAP equivalent), and
> the other URI is that this one requires the client know what "multiply"
> means.

Well both will require that, you need to know what the target will do with
your message anyway, otherwise, why doing discovery and description? :)
The main difference is that the SOAP message is typed, while the URI is
not.

> In the first URI above, "http://numbers.com/multiply" is entirely opaque.
> No information can be extracted from that URI string such that a user or
> machine can know that multiplication is occuring.
>
> In the second URI, the operation is part of a query parameter which is
> a less opaque part of the URI from the point of view of the client
> (though opacity of query parameters can be rigged with hidden form
> fields).

Well in the first URI you access a resorce that does one thing, multiply
two numbers. In the second one, you target a generic arithmetic processor.
Both are different resources, but both will do things that are cacheable,
and will respect the GET semantic (export one view of the object).

Also Content-Negotiation works also the same way, you target a resource
that will inspect the headers and try to delegate the processing to
another resource, the one that match the right language for example.
You are not asking the server to give you the best variant, but you ask a
live resource to give you the right content, as the semantic of "give me
the document in the language I want" is different that the semantic of the
object finally sent which is "give me this document".
And many servers are doing the mistake of not sending the
Content-Location: header to indicate the URI of the object that really
generated the content, but that's another story :)

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Received on Wednesday, 6 February 2002 05:29:29 UTC