From: Dan Brickley (Daniel.Brickley@bristol.ac.uk)
Date: Wed Mar 15 2000 - 23:50:05 PST
On Wed, 15 Mar 2000, Jeff Bone wrote:
> > It's called GET because it *means* GET; grab me a representation of the
> > state of the resource identified by this URI. INVOKE means nothing. You
> > can do INVOKE as a method extension, as a new header, or as part of the
> > payload body (like SOAP and XML-RPC). Any which way you slice it, none of
> > that means GET and is therefore not compatible with the architecture of the
> > Web.
>
> Oh, some on, you're not *really* going to make that argument, are you? GET maybe
> meant that back when the only browser out there was that NeXT doohickey. That
> whole purist notion has been out the window since early last decade. Let's be
> pragmatic. So "GET" isn't the right word. Fine --- rename it. Explain cgi-bin
> in the context of your semantic constraints. Are you against dynamic content in
> general? Or just the naming scheme that emerges, and the cognitive dissonance it
> sets up with the original design of HTTP? What's wrong with something like
>
> http://foo.host.com/class/object/method?arg=blah
>
> OR, if you like this better
>
> http://foo.host.com/class/object with <methodCall> ... in body?
>
> If the only answer to that question is "GET means GET, dammit" --- well, that's
> not a very compelling argument.
Here's another gloss on the dont-screw-with-GET objection. "GET means No
Side Effects". A GET asks for a content-type and language negotiated
_representation_ of some resource that's manifesting itself via the
HTTP protocol. If I do a GET on some HTTP-manifested object, I don't
want to end up in court waving RFCs around trying to prove that
my action couldn't have meant "add this to my shopping cart and
proceed directly to the e-checkout debiting my VISA credit card" or
"send a defamatory email to bill@whitehouse.gov". Doing a GET doesn't
mean that there'll be no state changes on the server (minimally, HTTP
server logs will grow), nor that the object we're asking for a
representation of must be a "file" (whatever those are). But by sending
a GET message to an HTTP-manifested object (or the server that manifests
it to the Web) it must be clear that I'm _only_ asking for a
representation of that object. If I want to screw about with it's state
or provoke it into making further actions on my behalf, we at least need
POST.
If the 'no side effects' interpretation of GET is diminished, Web
clients (human and otherwise) will have to scrutinise human- or machine-
readable small print from servers before daring to do GETs on unknown
objects. This is bad enough already in the limited domain of privacy
statements, eg. doing a GET on http://...some-site/privacystatements.xml
This requires some bootstrapping shared understanding between client
and server (in this case established through combination of semantics
established by knowledge of HTTP and P3P), eg. to ensure that the server
doesn't grab and sell details about me the first time I look at the
privacy statement.
By analogy, if I do a GET on the home page of some site, I should be
confident that I won't get a message saying "Thank You
For Signing Our Petition Against the Military Industrial Complex; your
IP address has been added to the Kill The President activists database".
Or rather, if some site did attempt that, I should be able to show that
my action, my GET message, in no way licensed them to act on my behalf
in such a way. If GET wasn't safe in this way, nobody would run web
indexers against the public Web.
Another take: anyone who is happy eroding the no-side-effects semantic
of GET should be wary of GETting previously unseen URIs, eg [1] [2].
IMHO etc.,
--danbri
[1] http://fork.really.fuckingsucks.net/ (not really :-)
[2] http://screwingwithgetsemantics.really.fuckingsucks.net/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 23:54:33 PST