W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2003

Re: Binding

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Tue, 7 Jan 2003 08:51:04 -0500
To: Miles Sabin <miles@milessabin.com>
Cc: www-ws-arch@w3.org
Message-ID: <OFDFB62D24.D59184A0-ON85256CA7.0047B3BF-85256CA7.004BEE60@rchland.ibm.com>
+1

My point exactly.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

www-ws-arch-request@w3.org wrote on 01/07/2003 07:47:21 AM:

> 
> Mark Baker wrote,
> > On Mon, Jan 06, 2003 at 09:54:13PM +0000, Miles Sabin wrote:
> > > But what if the consumer isn't a person? In general a machine won't
> > > know anything about that URI, it can't even guess. It won't
> > > autonomously follow it any more than it would follow any other link
> > > composed of a random string of characters. Unless, that is, it's a
> > > spider, in which case it'll blindly follow any link it's given ...
> > > but this is a list for Web _Services_ Architecture, not Web
> > > _Spider_ Architecture, and presumably we're all interested in
> > > getting machines to something a little more sophisticated than
> > > wandering blindly.
> >
> > You're absolutely right about only a spider wanting to invoke GET on
> > a URI without any other information available to it.  And in my
> > example, there was no other information.
> 
> So you agree that in *non*-spider cases some knowledge _is_ needed prior 

> to issuing a GET? Good.
> 
> Assuming we're not talking about a spider, do you agree that in the case 

> we've been discussing the client,
> 
> i)  has the URI http://www.stockquotes.com/ibm/lastshareprice.
> 
> ii) knows that issuing a GET on that URI will do something useful in the
>     context of the current interaction.
> 
> _before_ to issuing a GET, and that if the interaction is going to be 
> successful that implies some prior agreement with the server: in 
> addition to (i) and (ii) the server will have to be able to respond 
> appropriately GETs on that URI.
> 
> > > But note ... even if the machines are dumber in this case, the
> > > network has to be smarter. Qualitatively speaking, the same work
> > > that goes into the design and implementation of RPC-style clients
> > > and servers would have to go into the design and implementation of
> > > a REST-style network. And it's harder work, because the programming
> > > model and idioms are unfamiliar.
> >
> > This is where we disagree.
> >
> > If I understand your position, you believe that instead of POSTing
> > "getLastTradePriceOfIBM", a REST developer would need something
> > equivalent to;
> >
> > <lastTradePriceOfIBM>http://some-uri</lastTradePriceOfIBM>
> 
> That's more or less right.
> 
> > I don't believe that's the case. "lastTradePriceOfIBM" is only a
> > hint, an assertion that in the context of some other resource, that
> > the resource identified by that URI plays some role.  It doesn't
> > impact the form of binding in use (and therefore the coordination
> > properties), unlike a WSDL operation would.  It could just be
> > "quote", or "ibm-related-thing", or even
> > "things-of-interest-to-chris-and-heather". GET provides the
> > authoritative answer about the object type.
> 
> That's not good enough. Let's try a slightly less trivial example. 
> 
> Suppose,
> 
> * We have client wants to purchase 10,000 IBM shares iff the price is
>   less than 85 USD or sell 5,000 shares iff the price is greater than 86
>   USD.
> 
> * The client knows IBMs symbol ("IBM"), the URI of a stocktrading
>   service (http://trades.example) and how to use it.
> 
> * The client has an account with the stocktrading service (123-456-789).
> 
> Ignoring as many details as possible, the interaction might look 
> something like this,
> 
>    Client => Service
> 
>             Service => Client
> 
> 1. GET http://trades.example/quote-uri-for?symbol=IBM
> 
> 1'.         HTTP/1.1 200 OK
>             <uri>http://trades.example/ibm</uri>
> 
> 2. GET http://trades.example/ibm
> 
> 2'.         HTTP/1.1 200 OK
>             Expires: Tue, 07 Jan 2003 13:00:00 GMT
>             <quote>
>               <buy>
>                 <price>84</price>
>                 <uri>http://trades.example/ibm/buy/20030107130000</uri>
>               </buy>
>               <sell>
>                 <price>83</price>
>                 <uri>http://trades.example/ibm/sell/20030107130000</uri>
>               </buy>
>             </quote>
> 
> 3. POST http://trades.example/ibm/buy/20030107130000
>    <trade>
>      <quantity>10000</quantity>
>      <account>http://trades.example/accounts/123-456-789</account>
>    </trade>
> 
> 3'.         HTTP/1.1 200 OK
> 
> Initially the client queries the service for the quote URI for the stock 

> corresponding to "IBM" (1) and the service responds (1').
> 
> Then the client issues a GET on the returned URI (2) and in response 
> gets a time-limited quote (2'). The quote contains buy and sell prices 
> valid until the quote expires, and buy and sell URIs which are also 
> valid for the quote interval. If we're allowed to ignore URI opacity, 
> we'd notice that the server has returned identifiers of transient 
> resources corresponding to the time-limited bid and offer, 
> distinguished by an encoding of the expiry time in the URIs path 
> components ... note that the client doesn't have to understand that 
> encoding: it just has to act fast enough.
> 
> The client inspects the response, observes that the buy price meets its 
> constraints, and issues a POST on the buy URI to execute the 
> transaction, providing both the quantity and the URI corresponding to 
> its account with the service (3). The client has acted before the quote 
> expires and its account is in order, so the server acks the transaction 
> as having succeeded (3').
> 
> It's pretty clear that there's a set of interlocking expectations on the 

> part of the client and the server, for all that a large part of the 
> client-server interaction pattern is encoded in the structure of the 
> URI space which the server is supporting and which the client is 
> traversing. Prior to any interaction the client needs to know,
> 
> 1. How to form a query for a quote URI given the stock identifier "IBM".
> 
> 2. How to interpret the services response and extract the quote URI.
> 
> 3. That issuing a GET on the quote URI will take it one step further in
>    this buy/sell interaction by providing it with a quote.
> 
> 4. How to interpret the returned quote, in particular, that
>    quote/buy/price (resp. quote/sell/price) represents a price to
>    match against its constraints, and that quote/buy/uri (resp.
>    quote/sell/uri) represents a corresponding action.
> 
> 5. That issuing a POST with an entity of a particular form on the
>    appropriate URI will further its goals by initiating a trade.
> 
> On the other side of the interaction, the service has to know,
> 
> 1. How to respond to a query for a quote URI given the stock identifier
>    "IBM".
> 
> 2. How to generate a time-limited quote given a GET on a quote URI.
> 
> 3. How to update an account in response to a POSTed trade.
> 
> For all that the logical structure of this interaction is different from 

> the corresponding SOAP/WSDL interaction, it doesn't rely any less on 
> prior knowledge. At the very least it should be obvious that the client 
> has to know enough up front about the services response in (2') to be 
> able to distinguish between "buy" and "sell" ... otherwise it might 
> make an expensive mistake.
> 
> FWIW, I can imagine you quibbling about the details of the structure of 
> the URI space that's needed to support this kind of interaction ... 
> maybe you'd prefer to pick out different resources or transitions as 
> the salient ones. Whatever, that wouldn't materially affect the point: 
> it would still have to have _some_ structure, and there would still 
> have to be corresponding prior knowledge, shared context and 
> expectations between the client and the service.
> 
> Cheers,
> 
> 
> Miles
> 
Received on Tuesday, 7 January 2003 08:51:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:12 GMT