12

I know the differences between HTTP get and post methods (as expalined in big details in this question).
My question is why not always use the post method for AJAX calls, which is safe. Is there get request faster? is there is reason to prefer get then post?

For none ajax call there is a reason - to share a link to the same url, but for AJAX this argument it's not good...

Community
  • 1
  • 1
gdoron
  • 147,333
  • 58
  • 291
  • 367

4 Answers4

11

GET requests are smaller and faster; and leverage caching, both on the client side and on the part of any proxies that may be in play.

For data that isn't expected to change very often, GET requests are often very sensible, as they have a greater chance of not being resent unless necessary.

For data that is expected to change more often, however, POST is indeed the safer option, as it will always be resent to the server, making sure that changes are always respected.

There is also semantic issues that come into play. POST requests should really only be used when the intent is to modify data on the server.

Williham Totland
  • 28,471
  • 6
  • 52
  • 68
7

I was reading the Yahoo best practices for speeding up your websites some day back and they have very well explained why we should prefer get over post and here is the post snippet for your reference

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.

An interesting side affect is that POST without actually posting any data behaves like GET. Based on the HTTP specs, GET is meant for retrieving information, so it makes sense (semantically) to use GET when you're only requesting data, as opposed to sending data to be stored server-side.

For detail refer there page for details

Yahoo Best Practices for speed up

sonjz
  • 4,870
  • 3
  • 42
  • 60
Umesh Awasthi
  • 23,407
  • 37
  • 132
  • 204
5

My question is why not always use the post method for AJAX calls

Because in a RESTful application it wouldn't make sense to use the POST verb for actions that do not modify state on the server. In a RESTful application it doesn't really matter how the request was made: whether it was a normal, AJAX, or a robot.

Also GET requests are usually faster and are cached by browsers.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • 1
    The second part is enough to prefer GET then Post, But I wouldn't being convinced to _follow_ the REST standards it wasn't faster and cached. Is there other reasons not to use Post method for uncritical operations? – gdoron Dec 13 '11 at 11:03
  • @gdoron, personally I always follow REST standards in my applications, so this is the argument number 1 for me. – Darin Dimitrov Dec 13 '11 at 11:04
2

GET uses a single request to the server vs. two for POST.

According to Yahoo's YSlow team you should opt for GET when the content transmitted is less than IE's 2K limit. Read more here: http://developer.yahoo.com/performance/rules.html#ajax_get

Kenneth Benjamin
  • 378
  • 2
  • 16
  • 2
    What gives you the impression that a POST consists of 2 requests? – Gareth Dec 13 '11 at 09:54
  • @Gareth, maybe it was the link he provided...? – gdoron Dec 13 '11 at 11:29
  • 2
    @gdoron a TCP packet is not the same as an HTTP request. Any kind of request can be split into multiple TCP packets, it just happens that most (not all) browsers [use a minimum of 2 packets](http://josephscott.org/archives/2009/08/xmlhttprequest-xhr-uses-multiple-packets-for-http-post/) for an AJAX POST. Let's be clear that counting TCP packets is at best micro-optimisation, and micro-optimisation rarely gives a great answer for a question about whether you should "always" do something or not. – Gareth Dec 13 '11 at 12:58
  • 1
    @Gareth it's definitely _NOT_ micro-optimization in a process which mostly depends on latency - depending on circumstances (esp. latency) this can really make a difference. With 1 packet, server can process it right away, while with 2 packets you normally have the typical ack in between, which _may_ mean 2x end2end latency added. Also the possibility of a packet error increases by 100%, etc. Still, I agree with you that that shouldn't be taken as reason for "always" doing something. – griffin Aug 19 '13 at 09:11