- From: Burdett, David <david.burdett@commerceone.com>
- Date: Fri, 28 Feb 2003 03:33:05 -0800
- To: "'Mark Baker'" <distobj@acm.org>, "Burdett, David" <david.burdett@commerceone.com>
- Cc: "'www-ws-arch@w3.org '" <www-ws-arch@w3.org>
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