Re: Why GET is an application semantic

On Wed, Jun 19, 2002 at 09:56:08PM -0700, Joseph Hui wrote:
> Your system may get away with not knowing "get;" but it can't get away
> with not knowing "quotes/" (instead of "prices"),  "stocks/" (instead
> of "equities/"),  "sunw" (instead of "msft").  That is, it requires
> a priori info of some sort just the same.  If one really wants to stick
> with the protocol-intrinsic GET, then 
> http://Nasdaq.com/what=quotes&type=stocks&symbol=sunw would also work,
> though it comes across as a kluge.  My interest lies more in using
> named parameters (as opposed to positional parameters) for its
> superior flexibility than in "RESTing" orthodoxically.

Well, this is a separate issue (that I happen to disagree with, because
the URI could be http://www.yahoo.com/hv7q84f5334857 for all I care - 
i.e. it is opaque[1] to everybody but the publisher).

The purpose of this thread was to establish whether or not GET was an
application semantic.  I believe I described why it was, even when a
method is in the URI, at least when the client doesn't have to know what
the method name means (i.e. the URI remains opaque to it).  I also
described why the publisher could have problems with putting a method
name in the URI if doing so is requiring additional a priori agreement
between the two parties.

Maybe the horse is dead now. 8-)

 [1] http://www.w3.org/DesignIssues/Axioms.html#opaque

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

Received on Thursday, 20 June 2002 08:36:07 UTC