[decentralization] Re: REST and POST

[Mark Baker]

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

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
query results).

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

MB