3 ms·

In regards to ajax applications, is idempotence an important consideration? I use ajax/GETs to change server state, does this really matter? inklesspen's obje

by npk 19y ago

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?

dpapathanasiou 19y ago
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.
Bogtha 19y ago
> 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?

by npk 19y ago

dpapathanasiou 19y ago

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.

Bogtha 19y ago

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