5 ms·
Ask HN: Why would anyone POST anything in AJAX?
Bear with me here because I'm bound to take you off tangent, but as I've been developing more and more server-side oriented applications for HTTP I find myself pondering the advantages and disadvantages of implementation; so this may come across as an answer rather than a question. But wasn't AJAX created as a work-around for POST? Correct me if I'm wrong but POST is primarily a method for the server not the client, while GET behaves more like the web today (2.0) in that users spend more time requesting stuff (an xhr that passes some value who in turn returns with a response) from a server rather than writing or executing stuff on that server.
If anything AJAX seems like it was made especially for GET to cut-down on how much and what was being passed with POST...I might be way off, but does it not seem contradictory to POST something in AJAX without returning a response?
- aristus 17y agoNot at all. Imagine a document editor. There are limits to the amount of data that can be passed via GET URLs. Without POST you could only have 2KB documents. In Archivd we use POST via Ajax anywhere the user mutates data. It avoids the data length problem and makes it simpler to defend against CSRF attacks.
- mlLK 17y agoImagine a document editor. 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.
- boucher 17y ago280 Slides uses an asynchronous POST (or PUT) request for saving documents. 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.
- intranation 17y ago> For the web? Passing the entire document asynchronously? See Google Docs as an example of this.
- drawkbox 17y agoOk even if you do independent events eventually you want to upload an image or a file which is not going to fit in GET very well, the url path is limited to 2k. 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.
- bluefish 17y agoUsing POST doesn't necessarily make it simpler to defend against CSRF. You still need to use some kind of exclusive token shared between the client and server (e.g. a session id stored in a cookie). Imagine a poorly implemented site that doesn't prevent users from uploading js script blocks into the comments. A user could upload a script that creates a form and submits it via POST to your POST restricted endpoint, thus circumventing POST only protection. I'm assuming I've misread your comment as you use POST only and you're also doing proper CSRF protection right?
- cperciva 17y agoMany systems have limits on the maximum length of a GET query string, since said strings form part of a URL. In most cases these limits are quite large (4kB or more) but I've seen systems which can't even handle 1kB URLs. 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.
- jamroom 17y agoInternet Explorer has problems with URLs over 2047 characters in length - if you are needing to handle large amounts of text (say from a textarea), POST is the way to go.
- jaxn 17y agoIn addition to request size limits, using the HTTP methods on server side code can simplify code. If I GET a person record then send it down, if I POST a person record then process the passed parameters. With that separation I may find that POST requests do not require sending any data to the client (other than a success indicator). That reduces bandwidth and improves client response time. 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.
- pmjordan 17y agoThere are numerous implications of choosing POST or GET. 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.
- mlLK 17y agoAwesome. 5 things I now know that I probably would have not known for years to come by making mistakes. Without a whole lot of experience with AJAX + that nagging feeling I'm implementing it wrong, it's practical rules like these that I can easily put into practice. 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.
- mark-t 17y ago> Fourth, if web crawlers get hold of any URLs which exhibit side effects on GET, they will wreak havoc on your site. 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.
- gills 17y agoI use ajax POSTs for autosaves, creating and deleting 'child' objects (when the UI for the sub-object should be added to/removed from the page without a reload). Basically any mutation where I don't want a reload.
- cnlwsu 17y agoPOST easier to protect from XSS attacks when using the Django middleware.
- jim_lawless 17y agoGET parameters can ( and often do ) show up in web-server logs. Transmitting sensitive data via a GET ( even over SSL ) may ultimately cause security / privacy concerns.