Re: Binding

On Tue, Jan 07, 2003 at 09:54:25PM +0000, Miles Sabin wrote:
> > > 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.

I wouldn't call it a "discovery" phase.  It's just the first link
traversal, where the data returned happens to describe URI
structure, and binds known terms to URI parameters - exactly the same
thing that an HTML GET form does, only not for humans.

If we keep the interaction as it is, then this breaks the opacity
principle, as the client would need code which had specific knowledge of
the structure of the URI.  This would tightly couple the client to this
particular brokerage service.

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

Yes, but - and I admit I've done a poor job at explaining this - the
"a priori" information we're talking about here for the RESTful approach
is just the same a priori information needed to understand a schema.
There's nothing else that is needed - check above.  With WSDL, you need
the a priori information of how to process the schemas in use *and* the
a priori information of the interface to that data.

Do we agree to that last point, even if we may not agree on the impact
to the properties of the respective architectural styles?

Another way of looking at this, if you squint a little, is that spiders
don't have to be very general things like search engines, or maintenance
bots.  I could write a resumé collection and analysis spider who invokes
GET willy-nilly in its search for HRXML based resumes.  If it doesn't
find one behind a URI, it simply moves on to the next URI in its queue
that it earlier discovered.  The only a priori information required
there is the ability to spot URIs in arbitrary content.

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

Yes.

(ditto for 5)

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

There's degrees of "corresponds".  I think you believe it corresponds
very closely.  I believe it "slightly" corresponds, or in other words,
it's not coupled any more than it needs to be to get the job done, viz
a viz the form issue above.  I believe the use of WSDL is coupled much
more tightly than that.

So depending what you meant by "corresponds" ... 8-)

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

Only the "same role" in that they are both a priori information, if
that's what you mean.  They are different kinds of a priori information
used at different times, as I tried to explain above with the resumé
example.

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

See above.

> > 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 is the form issue; that the client doesn't have any code which can
interpret the semantics of a URI published by the service.

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

Is anybody following it?  If not, I'll drop it, because the cow
sub-thread seems to be making much more visible progress on the same
issue, IMO.

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

Received on Tuesday, 7 January 2003 20:49:53 UTC