Re: SOAP & REST

Not deeply different, no. One _interesting_ difference is that the
first can have subresources of the operation, e.g.,

  http://numbers.com/divide/remainder?...

whereas the other approach would need a new argument
 
  http://numbers.com/?operation="divide"&suboperation="remainder"

(arithmetic is perhaps a poor example here)

As a subresource, we know that there's a certain relationship between
the two resources; this is evident in such mechanisms as relative URIs.
If the operation is done with arguments, we lose this relationship.

Not earth-shattering, but it does give a means of composing
applications through the interrelation of resources that has some
nice properties. 



On Wed, Feb 06, 2002 at 09:28:40PM -0500, noah_mendelsohn@us.ibm.com wrote:
> 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
> 
> 

-- 
Mark Nottingham
http://www.mnot.net/

Received on Wednesday, 6 February 2002 22:15:58 UTC