News for hackers. Stuff that matters.
Re:GET to do POST's job -- when is it okay? by dpapathanasiou on Wednesday June 13, 2007 @10:11AM (#27789)
Remember that the spec's concept of GET for read only requests (idempotence, in the spec language) and POST for requests that change data on the server is just a recommendation.

There are places where breaking convention makes sense, e.g. using a POST for a read only query if you allow foreign language (non-ascii character) parameters.

If your only objection to POST is stylistic, I'd try the javascript suggestion by nostrademons.

Also, if you're going to go down the slippery slope of javascript and into ajax, note that XMLHttpRequest will let you do either GET or POST just as easily, by changing the method parameter in the open statement: http://developer.apple.com/internet/webcontent/xmlhttpreq.html

Re:GET to do POST's job -- when is it okay? by npk on Wednesday June 13, 2007 @04:45PM (#27881)
In regards to ajax applications, is idempotence an important consideration? I use ajax/GETs to change server state, does this really matter?

inklesspen's objections to GETs changing server state seem to be based on web-accelerators following links. If web accelerators do not parse js, then inklesspen's objections are not relevant. Am I correct?

Re:GET to do POST's job -- when is it okay? by dpapathanasiou on Wednesday June 13, 2007 @06:25PM (#27921)
In regards to ajax applications, is idempotence an important consideration? I use ajax/GETs to change server state, does this really matter?

Whether you use ajax or not, remember that all GET requests are formed, ultimately, into a url string.

So all the usual GET limitations apply, and there will always be cases where you wouldn't want to use GET (e.g., the list of parameters is very long, or if the parameters contain non-ascii characters, etc.), regardless if ajax is involved.

If web accelerators do not parse js, then inklesspen's objections are not relevant. Am I correct?

Yes, you're correct.

Because most of the accelerators/bots/spiders/etc. out there right now do not have javascript engines, they simply cannot click on an ajax GET link.

But don't be surprised if that changes in the future: some bot authors probably know they're being foiled by their inability to execute scripts, so I wouldn't be shocked to see javascript-capable crawlers clicking ajax GET links eventually.

Re:GET to do POST's job -- when is it okay? by Bogtha on Saturday June 16, 2007 @05:33PM (#28592)
> inklesspen's objections to GETs changing server state seem to be based on web-accelerators following links. If web accelerators do not parse js, then inklesspen's objections are not relevant. Am I correct?

No. GETs are defined to be safe by the HTTP specification. Web accelerators are only talked about so much because the problems GWA caused were so widely talked about. In reality, anything that see the URI can conceivably cause problems.

By abusing GETs in the way that you are, you're essentially gambling that no software is going to see and follow your links automatically. Right now, software like that might not exist. But you never know what fancy Firefox extension, UserJS script or proxy magic somebody could release tomorrow.

When it's so easy to use HTTP properly, is it really worth taking that kind of risk?