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

On Wed, Feb 26, 2003 at 08:22:11AM -0800, Burdett, David wrote:
> >>>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. 

Hmm, did I miss something there? 8-)  The application protocol
determines where the method goes.  For example, HTTP says;

"Request-Line   = Method SP Request-URI SP HTTP-Version CRLF"
 -- http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1

i.e. "not in the body" 8-)

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

No comment. 8-)

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

Great!

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

Ok, now I'm confused.  Just above, you described how to use GET as a
verb, with the URI identifying the noun.  But now you're saying the
verb/noun is buried in the body?

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

No.  #1 is perfectly suitable for complex operations.

Hmm, are you perhaps suggesting that GET/PUT/POST/DELETE are not
sufficiently expressable and are restricted to simple operations, and
therefore you need to put verbs/methods in the body for complex
operations?  That would appear to be consistent with your statements
above.  If you do believe this, then I have a question for you; try and
name a "complex operation" which can't be classified as one (and only
one) of these four things;

- retrieval of state
- an explicit setting of state
- the submission of state for processing
- the removal of state

There are operations that don't fit, but let's see if you can find any.
8-) I think you'll be surprised how hard it is, which should demonstrate
that REST can render even complex semantics.  And REST, BTW, isn't
restricted to just GET/PUT/POST/DELETE; any uniform semantic is fine
(I've talked about NOTIFY for pub/sub, for example, though that can also
be done with GET/PUT/POST/DELETE).

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

Received on Friday, 28 February 2003 01:46:50 UTC