

Use GET for AJAX Requests (or not) - fooyc

http://developer.yahoo.com/performance/rules.html#ajax_get<p>&#62; http://developer.yahoo.com/ says: when using XMLHttpRequest, POST is implemented in the browsers as a two-step process: sending the headers first, then sending data. So it's best to use GET, which only takes one TCP packet to send (unless you have a lot of cookies). The maximum URL length in IE is 2K, so if you send more than 2K data you might not be able to use GET.<p>Is it me, or is this "best practice" is really wrong ?<p>The statement that a POST request is sent in two packets is wrong. Thanks to TCP's Nagle algorithm, most POST requests are be sent in a single packet (at least POST requests that are small enough to be candidates for being sent as GET requests), even if the browser sends the data in two write() calls<p>Secondly, if you modify the server's state in a GET request you are violating the HTTP protocol. Since GET should not modify the server's state, the browser is allowed to e.g. pre-fetch the URL, or re-fetch it when the browser is re-opened, which may be unexpected by the developper (it could send a blog post comment twice, or worse, execute a payment twice).
======
0x5a177
I agree. I don't know about TCP behavior, but this seems really wrong in the
sense that it ignores HTTP semantics of GET and POST. I imagine this could
cause unintended effects in intermediaries like caching proxies.

------
bmelton
It's not clear to me which action the documentation is referring to, or what
specifically you're trying to accomplish.

The easy answer for me is that I use GET requests when I'm fetching data, POST
to create new data, PATCH to update existing data and PUT to mass-update
multiple records.

So, if you're speaking for a general purpose method, then I'd say you're
probably going to use GET most of the time, unless your app is more write-
heavy, then I'd recommend you use POST most of the time. Otherwise, I'd
suggest using the appropriate method for the action given.

