First off, the HTTP specification requires that GET (and HEAD) requests be idempotent^W EDIT: side effect free to enable caching. Clearly, violations of this abound; however, proxy servers and other infrastructure will often hold you to this rule, so make sure you know what you're doing. (proxies and clients are permitted to withhold or arbitrarily repeat GET requests without changing the outcome)

Second, security: although AJAX in the strictest sense falls under the same-origin policy, you can quite easily make GET requests to foreign hosts in JavaScript by creating SCRIPT, IMG or IFRAME elements with appropriate SRC attributes, whereas you'll struggle to create a foreign-host POST. Inappropriate use of GET is therefore the enabler of XSRF attacks. CAUTION: read petewarden's reply regarding XSRF attacks via POST forms.

Third, data size, as others have said. URLs are notoriously problematic for conveying any information other than short text.

Fourth, if web crawlers get hold of any URLs which exhibit side effects on GET, they will wreak havoc on your site. (though this can admittedly be alleviated by judicious use of robots.txt)

Finally, you seem to imply that POST requests will not or cannot generate a response similar to GET. This is not the case, responses to POST work in the same way. (except it must not be cached) The deciding factor is the nature of the request (side effect or no side effect), not the nature of the response.

Finally, you seem to imply that POST requests will not or cannot generate a response similar to GET. This is not the case, responses to POST work in the same way. (except it must not be cached) The deciding factor is the nature of the request (side effect or no side effect), not the nature of the response.

Yah I actually found this out right after I posted and had I known the difference between an AJAX POST and an AJAX GET was literally like 5 to 10 lines of code I may have never asked such an ostentatious question.

Don't let POST give you a false sense of security; checking the referrer can help in this particular case (it's tricky to forge the referrer from the client side) but you really need a robust check like a generated token to avoid malicious cross-site requests.

i've generally found that the client already has a cookie-session established in situations where cross-site ajax calls are a concern. so, my approach is to require a hash of <request text>+<session id cookie> as a per-call signature. javascript on another domain can't access the session id cookie and so won't be able to generate this signature.

If the security relies on other javascript not being able to access the session cookie, why is it insecure to use said session cookie by itself as the per-call signature?

Who can see the signature but not the session id cookie?

you're right that the remotely invoked request will include the sid as part of the http cookies header - it's what goes into the get/post request parameters which differentiates the domain context of the invoker. and if someone can't generate and include a sig because they can't access the sid, then the challenge might as well just be including the sid.

the only draw back i see is that i wouldn't have had an excuse to learn how to implement sha ;)

*edit: jim_lawless points out below that you might not want a sid showing up in web server logs. my system frequently rotates the clients sid, so it's not a concern to me - but if you do use less transient sid cookies you might want to implement the hash signature approach after all?

Web accelerators, too, and those will not be controlled by robots.txt. I would definitely advise the OP to read the HTTP spec about the differences between POST and GET, or perhaps an introduction to RESTful web development.

Technically, PUT request are supposed to be idempotent, while GET and HEAD are supposed to be side-effect free (which is strictly stronger than idempotency).

Or does the idempoten-cy apply only to the response from the server, and not the state of the data on the server?

Absolutely. User-agents are allowed to retry PUTs transparently -- it's only for POSTs that they're supposed to put up a "are you sure you want to re-submit this form? Bad stuff might happen" dialog.

For the web? Passing the entire document asynchronously?

In Archivd we use POST via Ajax anywhere the user mutates data.

See, I'm still new to AJAX and from the type of apps that I use and experiment with are generally broken down as independent events who pass values and who perform an xhr as each event is triggered. I guess as your app grows and the data your handling using this methodology (as GET) is suddenly just too complex to carry out on the client. Thanks for the input though.

Just because the mechanism for generating requests has changed, that doesn't mean the mechanics of REST should be thrown out the window.

REST is useful, and its how most of the infrastructure of the web works. It's useful to understand this, and try to build your applications appropriately.

POST you can pass much more information, also it is more secure in that is does not log the params and path in logs.

Or maybe you POST to a REST url that has some params such as an api_key, then you post the data structure. Or you want to post a large JSON object of all data on a page. Again limits to GET, so people choose POST then. It depends on the situation.

See Google Docs as an example of this.

If you want to send a large amount of form data and not have things randomly break, it's a good idea to use POST instead of GET.

I have really grown to appreciate this simplification while working with webpy on AppEngine. I think that my request handlers are about the cleanest they have ever been.