RE: Why GET is an application semantic

> -----Original Message-----
> From: Mark Baker []
> Sent: Wednesday, June 19, 2002 8:51 PM
> To: Joseph Hui
> Cc:
> Subject: Re: Why GET is an application semantic
> On Wed, Jun 19, 2002 at 08:12:45PM -0700, Joseph Hui wrote:
> > > Yes, but the implications for each choice on the ability 
> to deploy at
> > > Internet scale are tremendously different in each case.  
> So much so,
> > > that one is deployable on the Internet, and one isn't, in 
> my opinion
> > > and observation.
> > 
> > I'd done it (developed and deployed, though not with stock 
> quote apps)
> > the way I described, and it worked well every time. 
> > I think Yahoo did it in similar ways with their stockquote websites.
> Ah, ok, I think I'm clearer on what you mean now.
> So Yahoo may or may not do this with their stock quotes, I don't know.
> But that's the point - I *don't* need to know, I just use GET.
> So going back to your suggestion to change the URI to use "put"
> instead of "get" when I wanted to invoke PUT instead of GET, that *is*
> something that you are asking me, as a client, to know.  The REST
> contract says that if I have a URI for a resource, and I want to set
> it's state, I can use PUT *on that URI*.  But your system 
> doesn't allow
> that.  Instead, it requires that I know how to change the "get" to a
> "put" - something that I won't know to do without a priori information
> about your service.

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 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.

Joe Hui
Exodus, a Cable & Wireless service 

Received on Thursday, 20 June 2002 00:55:19 UTC