Comments on defunct: Why you should care about: idempotence and nullipo...

If you only care about modern browsers, you can al...

2011-07-29T20:44:03.158+05:30

If you only care about modern browsers, you can also use the history.replaceState method to turn your POSTed page into a GETtable page client-side, without a redirect. This got fixed in Bugzilla recently, so after you make changes to a bug you wind up with a usable URL in the location bar:
https://bugzilla.mozilla.org/show_bug.cgi?id=577720

Yeah, that's the standard solution. It's n...

2011-07-29T19:46:02.855+05:30

Yeah, that's the standard solution. It's not a hack either, because you're dividing the operation into a non-idempotent and an idempotent (well, nullipotent) part.

The "canonical" solution is for operatio...

2011-07-29T19:43:23.670+05:30

The "canonical" solution is for operations that "change the database" to use a POST request that return a redirect response.

In that way, you get the benefits of POST and pressing F5 on the returned page does not give you that horrible message and you don't repeat the post request, but the GET request that came after the browser was redirected.

That means handling GET and POST diferently on the server side which many web frameworks make really easy.

Plain old PHP is not one of them.

> On the flip side, you shouldn't use POST ...

2011-07-29T15:30:46.412+05:30

> On the flip side, you shouldn't use POST for
> an operation that would work with GET

Sometimes a POST ends up being used simply so that the parameters aren't exposed in the query string as they are with a GET. We recently had some code audited by a third party security firm who insisted that all calls to the back-end should be POSTs for precisely that reason.

Perhaps there's a need for a form of GET which puts the parameters in the request body, as with a POST, yet retains the nullipotency of GET.