Re: SOAP & REST

Regarding opacity, I am aware of the axiom, but you have to be careful how 
to interpret it. 

http://www.w3.org/TR/

isn't  particularly more opaque than 

http://numbers.com/multiply.

What is true of the opacity rule is that middleware and the network, and 
within reason the client and server, should not be computing on or 
inspecting the substructure of the URI.  Even the W3C web site in an 
important sense dispatches on TR vs. Member, to identify the resource, 
though at the next level up the entire URI is opaque.  The URI 
architecture explicitly embraces hierarchical URIs, which are in that 
sense not opaque when you're putting them together or serving them up. 

The only difference I see per web architecture between

http://numbers.com/multiply?inputnumber1="3"+inputnumber2="4"

and 

http://numbers.com/?operation="multiply"+inputnumber1="3"+inputnumber2="4"

is that we can guess that to implement both multiplication and division, 
the first style would result in two separate parameterized web resources 
(a multiplying resource, and a dividing resource) while the second would 
use a single parameterized resource (an arithmetic resource).  I don't see 
the two as deeply different from a web architecture point of view.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Mark Baker <distobj@acm.org>
02/05/2002 09:35 PM

 
        To:     Noah Mendelsohn/Cambridge/IBM@Lotus
        cc:     mnot@mnot.net ('Mark Nottingham'), skw@hplb.hpl.hp.com (Williams Stuart), 
xml-dist-app@w3.org
        Subject:        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 Wednesday, 6 February 2002 21:44:51 UTC