SOAP & REST

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

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

The relevant architectural principle here is;

http://www.w3.org/DesignIssues/Axioms.html#opaque

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

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

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

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