Re: Binding

On Mon, Jan 06, 2003 at 09:54:13PM +0000, Miles Sabin wrote:
> But what if the consumer isn't a person? In general a machine won't know 
> anything about that URI, it can't even guess. It won't autonomously 
> follow it any more than it would follow any other link composed of a 
> random string of characters. Unless, that is, it's a spider, in which 
> case it'll blindly follow any link it's given ... but this is a list 
> for Web _Services_ Architecture, not Web _Spider_ Architecture, and 
> presumably we're all interested in getting machines to something a 
> little more sophisticated than wandering blindly.

You're absolutely right about only a spider wanting to invoke GET on
a URI without any other information available to it.  And in my
example, there was no other information.

I think I understand the point you're trying to make now.  It didn't
twig before, because I consider this client-interpreted metadata to
be orthogonal to the binding issue.  So I still think you're wrong,
but we appear to be on common ground now.  Thanks for elaborating.

> If we want to do that, then we have to provide the machines with 
> something analogous to the shared context that makes link following 
> make sense in the human case. Machines being the dumb lumps of tin they 
> are, that has to be a priori shared knowledge and semantics encoded 
> some how or other.
> 
> The SOAP/WSDL way of doing that is to encode knowledge in the 
> communicating endpoints. The encoding is mostly ... code: and the 
> SOAP/WSDL community has given developers a programming model, idioms 
> and toolkits to help do the job of writing it.

Right.

> Another way of doing it might be to encode a significant portion of that 
> knowledge in the structure of the network that the machines are 
> traversing when they follow links. In a way, that's putting spiders to 
> work by designing the network they wander over in such a way that their 
> wandering produces a useful result. That this can be done is an insight 
> from the mobile calculii people, and, IMO, it's the echoes of this in 
> REST which makes REST interesting.

This is already commonly done to enable machine processing.  For
example, in XHTML;

<link rel="stylesheet" href="some-uri" />

> But note ... even if the machines are dumber in this case, the network 
> has to be smarter. Qualitatively speaking, the same work that goes into 
> the design and implementation of RPC-style clients and servers would 
> have to go into the design and implementation of a REST-style network. 
> And it's harder work, because the programming model and idioms are 
> unfamiliar.

This is where we disagree.

If I understand your position, you believe that instead of POSTing
"getLastTradePriceOfIBM", a REST developer would need something
equivalent to;

<lastTradePriceOfIBM>http://some-uri</lastTradePriceOfIBM>

I don't believe that's the case.  "lastTradePriceOfIBM" is only a hint,
an assertion that in the context of some other resource, that the
resource identified by that URI plays some role.  It doesn't impact the
form of binding in use (and therefore the coordination properties),
unlike a WSDL operation would.  It could just be "quote", or
"ibm-related-thing", or even "things-of-interest-to-chris-and-heather".
GET provides the authoritative answer about the object type.

For example, assuming that a URI was tagged with "ibm-related-things",
then an app written to grab and analyze stuff related to IBM would
want to recognize that element and invoke GET on the URI.  A wide
variety of forms of data could be returned for analysis, including
data that doesn't have anything to do with IBM; a runtime type
error (which should indicate that binding is still late).

BTW, I concluded that previous paragraph with a late binding comment
in the hope that you believe that late bound systems have lower
coordination costs.  But perhaps not.  If not, do you believe that
REST is late bound?  Just trying to figure out how to get to the
low-coordination-cost conclusion from here.

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

Received on Monday, 6 January 2003 20:55:53 UTC