Re: Binding

Mark Baker wrote,
> 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.

Hurrah!

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

OK, if you want to expand the scope of the interaction to include a 
discovery phase we could do that. But that'd only push the issue back 
one step. There has to be an initial URI to kick off with, and that'll 
need to be formed in much the same way, either that or something 
equivalent.

Let's not muddy the waters, and keep the interaction as is.

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

Granted.

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

That doesn't change things materially. The element name could be spelt 
"uri" or "quote" or "sdjkfsdfsk". What matters is that the client knows 
that at this point in the interaction the URI will do something useful 
for it.

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

And we agree that this hardcoding amounts to prior knowledge?

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

And we agree that this hardcoding amounts to prior knowledge?

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

And we agree that all this was by prior setup at the service end, and 
that the nature of the service provided corresponds to the hard-coding 
on the client end? Good.

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

So schemas and hard-coding play the same role in the RESTful model as 
WSDL and hard-coding in the RESTless model?

I'm comfortable with that. What I'd really like to know is why you think 
the one is preferable to the other.

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

Come again? ... how to manage to make "without any a priori knowledge" 
consistent with "the a priori knowledge is in the code"?

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

Nice try, but no cigar ;-)

Cheers,


Miles

Received on Tuesday, 7 January 2003 16:54:57 UTC