> What I _think_ one would typically do with HTTP independent of SOAP would 
> be something like sending a GET to:

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.

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

Right.  The difference between this URI (and its SOAP equivalent), and
the other URI is that this one requires the client know what "multiply"

The relevant architectural principle here is;

In the first URI above, "" 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

> Anyway, to net it out, my concerns in this note are:
> 1) to point out that in many cases, it is the _service_ that is the web 
> resource when we're building web services.
> 2) to ask those who understand REST better than I do how they would model 
> such a situation, with or without SOAP

I'd go with the former URI.

If you're now wondering how it is that some piece of software knows
the difference between a multiplication or a division service, that's
where hypertext comes in; an assertion needs to be made that the
resource is a "multiplier" (and there'll be some URI for that).

Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.

Received on Tuesday, 5 February 2002 21:46:08 UTC