RE: Why GET is an application semantic

> From: Mark Baker []
> Sent: Tuesday, June 18, 2002 9:07 PM
> To: Joseph Hui
> Cc:
> Subject: Re: Why GET is an application semantic
> Hi Joe,
> On Tue, Jun 18, 2002 at 07:52:28PM -0700, Joseph Hui wrote:
> > [GET]
> What does "get" help identify in that URI? 

The implementation-specific "get" function provided by,
which may choose to implement it through a CGI script or whatever. 
Note that may opt for several GET implementations,
allowing for method overloading at run time.
How's that for polymorphism in HTTP? ;-)

> What if I want to 
> invoke PUT on that URI, do I still need the "get"?

No, you'd use the "put" function as in:

> URIs and HTTP work together when HTTP provides the methods, and URIs
> provide the identifying information.  As soon as you try and make
> one do the job of the other, you run into all sorts of problems.
> A URI is like an object reference.  It's just a pointer.
> > I tend to read the HTTP GET as a protocol-intrinsic method upon 
> > which application semantics can be freely built (by app developers).
> > Am I "web-arch'ly incorrect" in this regard?
> 'fraid so. 8-(
> Would you consider building application semantics on top of
> getStockQuote()?  If so, what would that look like?  I've used this
> example before, to show how odd that would look;

The getStockQuote() method is not protocol-intrinsic.  
It didn't come with the HTTP 1.1 spec, for instance.

> String weather = getStockQuote( "getWeather( 'Ottawa' )" );
> 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? :-)


Joe Hui
Exodus, a Cable & Wireless service

> MB
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.     

Received on Wednesday, 19 June 2002 14:49:07 UTC