W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2003

Re: Binding

From: Mark Baker <distobj@acm.org>
Date: Mon, 6 Jan 2003 16:15:01 -0500
To: Geoff Arnold <Geoff.Arnold@Sun.COM>
Cc: www-ws-arch@w3.org
Message-ID: <20030106161501.R12258@www.markbaker.ca>

On Mon, Jan 06, 2003 at 12:35:08PM -0500, Geoff Arnold wrote:
> To avoid the apples vs. oranges problem, we need to start with the same 
> initial
> conditions and end up with the same final conditions.


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

The client *DOES* possess different information.  In addition to
knowing the structure of the request, it also possesses the knowledge
that it can invoke the GET method on any URI, the same way that somebody
seeing an nfs:// URI knows they can invoke READ on it, or an FTP URI can
have RETR invoked on it (of course, they can invoke *any* method of the
associated application protocol, but "retrieve"-like methods are the
obvious one to mention in an example).

And not to suggest that FTP and NFS are all REST systems; they're not. 
But they all associate an application protocol with an identifier, and
then export that identifer into URI space by associating the
protocol (or more generally its coordination semantics) with the URI

Please(!), think about that for a sec.

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

And now for something completely different. 8-)

Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
Received on Monday, 6 January 2003 16:14:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:02 UTC