Re: Binding

> <sigh/>
>
> And the RESTless version could work just as well if we substituted
> "9ajp23q9rj89aweruwer" for "getLastSharePriceOfIBM". What allows this,
> in *both* cases is the _prior_ coordination between the client which
> has,
>
>   http://www.stockquotes.com/9ajp23q9rj89aweruwer
>
> or,
>
>   http://www.stockquotes.com/  and  9ajp23q9rj89aweruwer
>
> and the server which is able to respond appropriately to,
>
>   a GET of http://www.stockquotes.com/9ajp23q9rj89aweruwer
>
> or,
>
>   a POST to http://www.stockquotes.com/ with 9ajp23q9rj89aweruwer in 
> the
>   request entity.
>

+1

Dotting the i's and crossing the t's here:

To avoid the apples vs. oranges problem, we need to start with the same 
initial
conditions and end up with the same final conditions.

Initially, the server knows:
- the price of "IBM"
- the structure of a request for a share price
- the structure of a response
And the client knows:
- the structure of a request
- the structure of a response
- the name of the stock - "IBM"
- information that allows it to address the service

Here "structure" may take various forms. It may use explicit encodings, 
such
as XML schemata, or purely operational mechanisms for interpreting or
composing messages. (It may also be decided JIT - don't complicate 
things
with the binding issue, please.) The "information for addressing" may
be a URI, or attributes for a UDDI lookup, or something equivalent. It 
is *not*
legitimate to assert that the client possesses different information in
the REST and non-REST cases, which is what Mark seems to be doing.

At the conclusion of the interaction (either RESTfully or 
non-RESTfully),
we have exactly the same postconditions in both cases.
The client has all of its original information, plus the share
price of "IBM". The server has all of its original information, plus
(if it cares) the fact that the client has been provided with the
information.

Over to you, Mark. Or not.

Geoff

Received on Monday, 6 January 2003 12:33:22 UTC