51

I am new to web programming and just curious to know about the GET and POST methods of sending data from one page to another.

It is said that the GET method is faster than POST but I don't know why. One reason I could find is that GET can take only 255 characters? Is there any other reason? Please someone explain to me.

Boann
  • 48,794
  • 16
  • 117
  • 146
Embedd_0913
  • 16,125
  • 37
  • 97
  • 135
  • 12
    You should choose GET vs POST based on whether the action has side effects, not any perceived performance difference. – Draemon Jul 31 '09 at 10:47

8 Answers8

52

It's not much about speed. There are plenty of cases where POST is more applicable. For example, search engines will index GET URLs and browsers can bookmark them and make them show up in history. As a result, if you take actions like modifying a DB based on a GET request, it might be harmful as some bots might also traverse the URL.

The other case can be security issue. If you post credentials using GET, it'll get listed in browser history and server log files.

Mehrdad Afshari
  • 414,610
  • 91
  • 852
  • 789
  • how these methods works is there some kind of serialization used to store values and then deserialization for getting the stored data. – Embedd_0913 Jul 31 '09 at 10:57
  • 1
    For simple form submission, both rely on key value pairs. GET embeds those in the URL itself (query string) and POST sends it in the body of the request. – Mehrdad Afshari Jul 31 '09 at 11:18
  • Then there are issues about length of the URL. Even if you are doing an action which might otherwise be a GET (like a simple search lookup) you are constrained by the length of what is allowed by GET and might be forced to choose POST. – demongolem Feb 21 '12 at 16:30
  • Unless it is an internal GET request. That is, made by your application to the backend, i.e. next js. Search engines shouldn't be picking these up. – anastymous Apr 27 '23 at 11:14
31

There are several misconceptions about GET and POST in HTTP. There is one primary difference, GET must be idempotent while POST does not have to be. What this means is that GETs cause no side effects, i.e I can send a GET to a web application as many times as I want to (think hitting Ctrl+R or F5 many times) and the requests will be 'safe'

I cannot do that with POST, a POST may change data on the server. For example, if I order an item on the web the item should be added with a POST because state is changed on the server, the number of items I've added has increased by 1. If I did this with a POST and hit refresh in the browser the browser warns me, if I do it with a GET the browser will simply send the request.

On the server GET vs POST is pure convention, i.e. it's up to me as a developer to ensure that I code the POST on the server to not repeat the call. There are various ways of doing this but that's another question.

To actually answer the question if I use GET or POST to perform the same task there is no performance difference.

You can read the RFC (http://www.w3.org/Protocols/rfc2616/rfc2616.html) for more details.

Kevin Jones
  • 2,369
  • 16
  • 26
  • Thank for your suggestion that POST is used so that repeated call cannot be happened on the server side. – Frank Myat Thu Mar 28 '14 at 04:26
  • That isn't what he said frank, post COULD result in changes, however there is no guarantee post changes anything, it could just be because posting data is more optimal for the use-case than using the url, there is no mandated rule that states post changes something – Christopher Thomas Mar 11 '15 at 13:15
11

Looking at the http protocol, POST or GET should be equally easy and fast to parse. I would argue, there is no performance difference.

Take a look at the raw HTTP headers

http GET

GET /index.html?userid=joe&password=guessme HTTP/1.1
Host: www.mysite.com
User-Agent: Mozilla/4.0

http POST

POST /login.jsp HTTP/1.1
Host: www.mysite.com
User-Agent: Mozilla/4.0
Content-Length: 27
Content-Type: application/x-www-form-urlencoded

userid=joe&password=guessme

From my point of view, performance should not be considered when comparing GET and POST.

Robert
  • 1,466
  • 10
  • 25
  • 9
    GET is less packets then POST. Which shows in your example. Always packets if lesser then more faster to process. The more large packets even in a single byte is at-least somewhere in memor/cpu its extra implementation. So comparing GET or POST, i would say according to packet size GET will be faster. –  Mar 15 '12 at 16:29
  • @YumYumYum +1. In my applicated GET is 2x faster than POST! – Jack Mar 16 '14 at 03:10
11

You should think of GET as "a place to go", and POST as "doing something". For example, a search form should be submitted using GET because the search result page is a "place" and the user will want to bookmark it or retrieve it from their history at a later date. If you submit the form using POST the user can only recreate the page by submitting the form again. On the other hand, if you were to perform an action such as clicking a delete button, you would not want to submit this with GET, as the action would be repeated whenever the user returned to the URL.

Tim Booker
  • 2,801
  • 1
  • 25
  • 36
7

Just my few cents from 2016.

I am creating a simple message system. At first I used POST to receive new alerts. In jQuery I had:

$.post('/a/alerts', 'stamp=' + STAMP, function(result)
{
});

And in PHP I used $_POST['stamp']. Even from localhost I got 90-100 ms for every request like this. I simply changed:

$.get('/a/alerts?stamp=' + STAMP, function(result)
{
});

and in PHP switched to $_GET['stamp']. So a little less than 1 minute of changes. Now every request takes 30-40 ms.

So GET can be twice as fast as POST. Of course not always but for small amounts of data I get same results all the time.

Tom
  • 2,962
  • 3
  • 39
  • 69
4

GET is slightly faster because the values are sent in the header unlike the POST the values are sent in the request body, in the format that the content type specifies.

Usually the content type is application/x-www-form-urlencoded, so the request body uses the same format as the query string:

parameter=value&also=another When you use a file upload in the form, you use the multipart/form-data encoding instead, which has a different format. It's more complicated.

Waqleh
  • 9,741
  • 8
  • 65
  • 103
2

I agree with other answers, but it was not mentioned that GET requests can be cached while POST requests are never cached. I think this is the main reason for some GET request being performed faster. (Of-coarse this means that sometimes no request is actually sent. Hence it's not actually the GET request which is faster, but your browser's cache.)

HTTP Methods: GET vs. POST: http://www.w3schools.com/tags/ref_httpmethods.asp

AXO
  • 8,198
  • 6
  • 62
  • 63
0

POST will grow your headers more, just making it larger, but the difference ought to be negligible really, so I don't see why this should be a concern.

Just bear in mind that the proper way to speak HTTP is to use GET only for actions and POST for data. You don't have to, but you also don't want to have a case where Google bots can, for example, insert, delete or manipulate data that was only meant for a human to handle simply because it is following the links it finds.

Hans
  • 1,292
  • 9
  • 7
  • 1
    This is not entirely true. To clarify: GET is meant to be idempotent and generally has no body. POST is not necessarily idempotent and generally has a body. Note, I say that GET "generally" has no body because the HTTP spec does not disallow it (IIRC) but most servers will probably ignore it. – Tom Dec 23 '10 at 19:23