RE: Why GET is an application semantic

> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Wednesday, June 19, 2002 1:57 PM
> To: Joseph Hui
> Cc: www-ws-arch@w3.org
> Subject: Re: Why GET is an application semantic
> 
> 
> On Wed, Jun 19, 2002 at 01:38:02PM -0700, Joseph Hui wrote:
> > I might, just to be perfectly explicit, 
> > though there's no fundamental difference in 
> >   
> >     http://nasdaq.org/quotes/stock/sunw vs
> >     http://nasdaq.org/get?what=quotes&type=stock&symbol=sunw
> 
> The difference, as you've described by the purpose of "get" there, is
> that the former identifies a resource, while the latter identifies an
> operation performed on a resource.
> 
> That's a pretty big difference.
> 
> > in terms of method invocation.  If GET is understood, then
> > the method name is implicit in the former, and explicit in
> > the latter.
> 
> Right.
> 
> >  The explicit approach allows for get1, get2, ...
> > to overload the same GET, say: get1 for realtime quotes, which
> > fetches data from a trading floor environment; get2 for delayed
> > quotes, which routes data from some news organization; ...
> > (Of course, the realtime/delayed options can be astracted into
> > a parameter of a generic get method.)
> 
> Why wouldn't
> 
>   http://nasdaq.org/quotes/stock/sunw/realtime
> 
> suffice for identifying a realtime quote?  

No arguement from me about identifying a resource,
in this case, a realtime quote.  But if one is also
interested in the operational aspect, then unless
the "quotes/" is understood within the nasdaq.org
context to be getting quotes, then there's the
ambiguity of "put" or "get" not being expressed
in the URI.

> Why do you need "get1" or "get2"?

For two functionally different implementations.  

As I had said above (previously), one may squash the
two into one generic function and parameterize the
realtime/delayed difference into an option for the caller.
It's a designer's choice.

> 
> > Actually, the most salient difference between the two (URIs)
> > lies in the form of parameter passing.  The former uses positional
> > parameters; the latter uses named parameters, to allow for superior
> > flexibility in situations where a caller only concerns itself
> > with few options out of many, e.g. to get a currency-exchange quote:
> > 
> > http://nasdaq.org/get?what=quotes&type=currencyexchange&curr1=USD&curr2=EUR

> Sorry, I don't understand.  I see putting the method in the URI as
> confusing roles. 

Again, it's IMO a designer's choice.  I don't see it confusing that
a task dispatcher is handeled over a URI, parses it, and decides
which method/function to invoke (with the parameter values extracted
from the same URI).

> A URI identifies a resource - something with state
> and identity, like an object.

A web resource, "like an object" as you said, can have an operation
aspect to it.  As an object can encapsulate data and method in its
definition, why can't a URI?  What am I missing?

Joe Hui
Exodus, a Cable & Wireless service
===================================================


MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Wednesday, 19 June 2002 17:28:29 UTC