RE: Why GET is an application semantic

> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Wednesday, June 19, 2002 12:42 PM
> To: Joseph Hui
> Cc: www-ws-arch@w3.org
> Subject: Re: Why GET is an application semantic
> 
> 
> On Wed, Jun 19, 2002 at 11:49:56AM -0700, Joseph Hui wrote:
> > > On Tue, Jun 18, 2002 at 07:52:28PM -0700, Joseph Hui wrote:
> > > > [GET] http://nasdaq.org/get?what=quotes&type=stock&symbol=sunw
> > > 
> > > What does "get" help identify in that URI? 
> > 
> > The implementation-specific "get" function provided by nasdaq.org,
> > which may choose to implement it through a CGI script or whatever. 
> > Note that nasdaq.org may opt for several GET implementations,
> > allowing for method overloading at run time.
> > How's that for polymorphism in HTTP? ;-)
> 
> Heh. 8-)
> 
> But Nasdaq can already hide the CGI script behind the URI.
> 
> e.g. http://nasdaq.org/quotes/stock/sunw
> 
> can be bound, by whatever Web server they're using, to a CGI.
> There's no need to have a "get.cgi" exposed in the URI.
> 
> The URI is just like a CORBA object reference in this regard.  You
> wouldn't want a method name in a CORBA object reference, 
> would you? 8-)

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

in terms of method invocation.  If GET is understood, then
the method name is implicit in the former, and explicit in
the latter.  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.)

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

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

> 
> > > That's called tunneling.
> > 
> > Or overloading, perhaps?  The first thing comes to mind when
> > "tunneling" is mentioned tends to be "blind relay," e.g. a
> > transparent proxy, when HTTP is spoken of.  That's IMHO at
> > least the case among CDN (Content Delivery Network) jocks,
> > in the spirit of HTTP 1.0 and 1.1.
> > 
> > BTW, as far back as I can recall, the "tunneling" term was
> > initially coined by networking folks to mean transporting
> > network-level packets of one protocol as the data payload
> > of another protocol (at pretty much the same layer in an OSI
> > stack), e.g. an IP tunnel in X.25.  These days, I find it
> > necessary to check the context of discussion more carefully
> > in order not to misinterpret the writer or speaker's true
> > intent for "tunneling" as a term.
> > Anyway, tunneling is what tunneling is, or may be.
> > As long as we understand each other, what's big deal right? :-)
> 
> 8-)  Right, that's the definition I'm using.  In my weather/stock
> example, the "weather application protocol" is tunneling through
> the "stock quote application protocol".
> 
> 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 16:37:25 UTC