Re: Binding

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.

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?

Cheers,


Miles