Re: Binding

On Mon, Jan 06, 2003 at 08:38:24AM +0000, Miles Sabin wrote:
> Mark Baker wrote,
> > On Sun, Jan 05, 2003 at 08:54:15PM +0000, Miles Sabin wrote:
> > > OK then, why would you be able to postpone the decision to GET
> > > http://www.stockquotes.com/ibm/lastshareprice more than the
> > > decision to POST an entity containing getLastSharePriceOfIBM?
> >
> > The decision that's being postponed in the case of GET *is* to invoke
> > getLastSharePriceOfIBM.  It's not part of the interface, because GET
> > and the URI are providing an abstraction.
> >
> > In the tunnel-over-POST case, getLastSharePriceOfIBM is the explicit
> > semantic being requested in the message, and its binding can
> > therefore not be delayed.
> >
> > Ok?
> 
> Not OK.

Why?  What's wrong with that response?  I thought it was quite succinct.
In the former, "getLastSharePriceOfIBM" is postponed; it's an invocation
hidden from the client during dispatch.

A comparison, from some OO textbook.

Suppose we had two classes, a square and a circle;

Class Square
{
  displaySquare()
}

Class Circle
{
  displayCircle()
}

and an abstraction for both;

interface Shape
{
  display()
}

The Web services approach is analogous to interacting directly with
the Square and Circle classes.  The Web approach is analogous to
interacting with Shape, which uses late binding to bind an inbound
"display()" message to either the displaySquare() or displayCircle()
operations.

> In the REST case we have to have,
> 
> 1.  A server that can return a useful representation in response to a
>     GET of http://www.stockquotes.com/ibm/lastshareprice.
> 
> 2.  A client application that can determine that a GET issued on 
>     http://www.stockquotes.com/ibm/lastshareprice will make a useful
>     step forward in the interaction between it and the server.
> 
> In the RESTless case we have to have,
> 
> 1'. A server that can return a useful representation in response to a
>     POST with getLastSharePriceOfIBM in the request entity.
> 
> 2'. A client application that can determine that a POST issued with
>     getLastSharePriceOfIBM in the request entity will make a useful
>     step forward in the interaction between it and the server.
> 
> If I understand your response correctly, you're saying that (2) is more 
> easily satisfied than (2').
> 
> Why?

(2) doesn't require that the client posess any additional a priori
information than what's in RFCs 2616 and 2396 in order to get the
data; (2') does.

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

Received on Monday, 6 January 2003 10:08:50 UTC