Re: Binding

On Tue, Jan 07, 2003 at 12:47:21PM +0000, Miles Sabin wrote:
> So you agree that in *non*-spider cases some knowledge _is_ needed prior 
> to issuing a GET? Good.

Yes.

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

Ok.

> ii) knows that issuing a GET on that URI will do something useful in the
>     context of the current interaction.

See below.

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

Well, I disagree for esoteric but important-on-a-large-scale reasons.
But I don't consider those significant for this example, so ok.

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

It can discover this as part of an interaction, equivalent to a
machine processable GET form.

> 2. How to interpret the services response and extract the quote URI.

I'd use redirection there, to prevent the client from having to
understand that there's a separate lookup step.  So from their POV,
they'd just enter IBM, and they'd get back a quote after doing a
blind redirect (*good* automata 8-).

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

That sort of information should be made available in the data.  So
instead of "<uri>..</uri>", it should be "<quote>..</quote>" or
similar.

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

Yes, it's hardcoded to understand that schema.

> 5. That issuing a POST with an entity of a particular form on the
>    appropriate URI will further its goals by initiating a trade.

Because it's been hardcoded to know that based on where the URI was
discovered in the document.

The nested <buy><uri>..</uri><buy> construct in your example provides
this information.  More simply, it could be done as;

  <buy-order-processor>http://...</buy-order-processor>

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

The service has provided the form, as I explained above, so it's in
complete control here;  No problem-o.

> 2. How to generate a time-limited quote given a GET on a quote URI.

Right.  Nothing unusual there.

> 3. How to update an account in response to a POSTed trade.

Ditto.

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

The difference between WSDL based knowledge, and REST based knowledge,
is that REST's knowledge doesn't impact the binding qualities of the
interaction.  So a client written to know how to place trades, can do
so with any service that supports the same schemas.  A Web services
approach requires that *both* interface and schemas match up.

The structure of URI space is *completely* irrelevant, because the
service creates the URIs, and clients use them opaquely without any a
priori knowledge of what each one is; the a priori knowledge is in the
code that interprets the schemas and understands what it means for some
token, such as a URI, to be in a particular place.  The first point #3
above demonstrates this.

This discussion has become pretty obscure now, I'd say.  The point seems
to be buried deeper under successive responses.  I think she's dead,
Jim.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis