- From: Walden Mathews <waldenm@optonline.net>
- Date: Thu, 02 Jan 2003 17:54:17 -0500
- To: David Orchard <dorchard@bea.com>, "'Champion, Mike'" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org
Dave, ----- Original Message ----- From: "David Orchard" <dorchard@bea.com> To: "'Champion, Mike'" <Mike.Champion@SoftwareAG-USA.com>; <www-ws-arch@w3.org> Sent: Thursday, January 02, 2003 12:38 PM Subject: RE: Issue 5; GET vs GetLastTradePrice > > Mike, > > Interesting POV. I offer my limited analysis. The web is optimized for > ad-hoc retrieval of resources, specifically around using GET. It's the > default method given only a URI. Therefore people can easily post (:-) them > on billboards, send via email etc. > [snip] > IMO, ad-hoc retrieval of representations doesn't make as much sense in a > machine to machine world, as compared to a hypermedia world. > > The architectural middle ground that I believe we are moving towards is a > model that is optimized for program creation - hence the necessity of wsdl - > and allowing for ad-hoc invocation - hence the support for GET. The > optimization is different, but the features are supported. I also believe > that the default method for web services will be the POST method. > I know what 'ad hoc' means (or thought I did), but I'm confused as to what you mean by it in the above paragraphs. Could you please clarify? Is there such a thing in your book as a retrieval that's not 'ad hoc'? Another thing, you might be saying (in the "IMO" paragraph) that fully automated applications will push more than they will pull, and that that distinguishes them from browser-based ones. I found last summer that when I proposed machine-to-machine design around hypertext, various people grumbled that "browsing" might be suboptimal. But when we did our design for error handling, we saw the value of "browsing" when client and server are loosely coupled and talking over an expensive link. If this is indeed what you're talking about above, maybe I could tell you more about my experience. I think that loosely coupled parties, whether they be machines or humans, should "browse" in order to avoid getting swamped in each other's error conditions. "Browsing" behavior is not mandated by REST, but it proved useful in surprising ways. There's an optimization you can reach in which expensive missteps (into invalid states) are largely avoided. Have you considered that one in your analysis of optimizations above? Walden
Received on Thursday, 2 January 2003 17:54:26 UTC