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

One last try ... you asked ...

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

You are right, you can any operation fit the REST model - don't think anyone
would argue against that. But that does not necessarily may it "right". For
example a family of six could live in a one room apartment, but that's not
necesarily a "right thing" to do. You *need* to make the solution a good fit
to the problem you are trying to solve.

This is why, even though you *can* do it using REST you should not for
reasons of privacy, transport-protocol independence, message integrity as
specified in [1], and for the need to record information over and above a
simple "POST" as described in [2]. Using POST with a URI is not the "right"
way to do it when you want to use the web as a "low cost, protocol
independent, ubiquitous method for moving information around".

My guess, though, is that we will just have to agree to disagree.

David



[1] http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0274.html
[2] http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0207.html

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Thursday, February 27, 2003 10:50 PM
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.


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 06:33:37 UTC