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