[decentralization] Re: REST and POST
Thu, 23 Aug 2001 15:17:25 -0400 (EDT)
> > There
> > are good reasons for ensuring that GET remains the only method with which a
> > representation can be returned without side-effect a priori (i.e. if sometimes
> > the POST left a side-effect, and sometimes it didn't, then POST is the right
> > method).
> Pardon, but that's exactly my point. There's no relation between the literal
> characteristics of GET and POST and the broader issue of whether they have side
One of us misunderstood the other, because that's incorrect. For a given
resource, as a client, invoking POST means accepting that the server may or
may not change state - you don't know. Invoking GET means that you can
*assume* that the state doesn't change because of your GET (even though
the server can change the state, the client won't care).
> Unless someone can make a case that using STDIN instead of the query string
> necessarily means side effects, the fix is to allow STDIN packaging for
> operations without side effects a priori.
Do you really want to have to go to the trouble of deploying this?
How will existing browsers know to do this? How will I represent one of
these things in a TV ad?
> A new method GET-STDIN with the
> syntax of POST and the semantics of GET?
See that "axiom" again. If there's another idempotent method, how do
we know which one to use for a given URL?
> An additional header
> X-no-side-effects? Dunno.
Or work with what's there, and suck up the extra round trip in that
example I gave (and gain other advantages, like being able to share
> Programmers need STDIN packaging constantly. That's not going to change,
> regardless of how you model interactions.
Tough nuts! 8-) GET's out of the bag, and working very well.
If you want STDIN, do what I suggested in that query example.