W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2003

Re: Issue 5; GET vs GetLastTradePrice

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
Message-id: <003d01c2b2b1$e10127a0$1702a8c0@WorkGroup>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:12 GMT