RE: Visibility (was Re: Introducing the Service Oriented Architec tural style, and it's constraints and properties.

>>>The *critical* thing that one has to accept in order to understand REST,
is that application protocol methods are the same as operations in an
API,<<<

I agree. The only debate is where within the message you put the
method/operation. 

>>>If you just take this as a given for a moment, you'll
see that all the arguments I've ever made on this subject become a big,
complex, yet entirely self-consistent description of much of Web
architecture, and indeed several other Internet scale architectures.<<<

I agree with the *much* as in ".. *much* of the Web Architecture" but you
did not say all as in "... *all* of the Web Architecture". Recent email
threads have identified an equally valid model for using *web technology* as
"a low cost, protocol independent, ubiquitous method for moving information
around". The "methods/operations" associated with this second use case must
often be private, secure, and transport protocol independent.

>>>So, a *rhetorical* question for those of you who don't believe that
GET is at the same layer as getStockQuote; ...<<<

Firstly I do believe that "GET" is at the same layer as getStockQuote, since
getStockQuote is clearly doing a "get" and therfore using GET as the
operation makes sense. All operations consist of two items: a) the verb, and
b) the object of the verb as in "get, stockquote", "archive, order", "offer,
order" where each of the verbs and nouns need to have their semantics
defined so that they can be properly defined

>>>... what would you call a protocol that does have a "getStockQuote"
method?  Note; "application protocol" is already taken. 8-)<<<

I think I would call it a messaging protocol as it is a protocol designed to
*just* move data around in potentially a secure reliable way. What you do
(i.e. the verb/noun) is buried in the payload somewhere for reasons of
privacy/security and transport protocol independence which is the opposite
of the visibility provided by putting the method in the transport. In both
cases you still have the same verb/noun combination although you are
representing them differently.

I think that both use cases can simultaneously exist as they are solving
different problems and each provide significant advantages:
1. REST, visibility, caching & simplicity for "simple" operations
2. MESSAGING, privacy, security, transport independence and flexibility for
complex operations.

Mark, do you agree that both should exist?

David

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Wednesday, February 26, 2003 8:01 AM
To: Burdett, David
Cc: 'www-ws-arch@w3.org '
Subject: Re: Visibility (was Re: Introducing the Service Oriented
Architec tural style, and it's constraints and properties.


> Do I detect a trout hole again ... anyway here goes ... comments in line
...

Yes, we're quickly closing in on well worn arguments, so I'll leave it
at this, which *has* already been said, but not recently ...

On Wed, Feb 26, 2003 at 03:18:48AM -0800, Burdett, David wrote:
> <DB>We need to define what we mean by an "application" if you mean it is
> anything above the transport layer, then you are correct but really I
think
> the layers are typically: Operating System, App Server, "Web Services
> Middleware", Application.

The *critical* thing that one has to accept in order to understand REST,
is that application protocol methods are the same as operations in an
API, i.e. at the same layer of the stack as "getStockQuote" or
"purchaseBook".  If you just take this as a given for a moment, you'll
see that all the arguments I've ever made on this subject become a big,
complex, yet entirely self-consistent description of much of Web
architecture, and indeed several other Internet scale architectures.  If
you don't accept it, then I probably come off as a loon, which I
completely understand because I thought the same thing of some guys who
saying that to me back in 97/98 (Dan Connolly and Roy Fielding, FWIW).

So, a *rhetorical* question for those of you who don't believe that
GET is at the same layer as getStockQuote; what would you call a
protocol that does have a "getStockQuote" method?  Note; "application
protocol" is already taken. 8-)

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