Re: Binding

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 07:47:53 UTC