Take the 2-minute tour ×

All over the internet, I see the following advice:

A GET should never change data on the server- use a POST request for that

What is the basis for this idea?

If I make a php service which inserts data in the database, and pass it parameters in the GET query string, why is that wrong? (I am using prepared statements, to take care of SQL Injection). Is a POST request in some way more secure?

Or is there some historic reason for this? If so how valid is this advice today?

share|improve this question
Command/query separation. –  Mason Wheeler Mar 1 '13 at 18:33
Thank you for asking this question, and thank you @Oded for the well phrased answer I always needed a reference to send people who ask this question towards :) –  Benjamin Gruenbaum Mar 1 '13 at 18:43
Also see HTTP PUT - stackoverflow.com/questions/630453/put-vs-post-in-rest (with notes about being idempotent) –  Bratch Mar 1 '13 at 19:52
@JoachimSauer While GET would have saved them from the crawler, the root problem was lack of authentication. Any script kiddy could have POSTed them into oblivion as well. –  CodesInChaos Mar 2 '13 at 16:20
show 2 more comments

5 Answers

up vote 126 down vote accepted

This is not advice.

A GET is defined in this way in the HTTP protocol. It is supposed to be idempotent and safe.

As for why - a GET can be cached and in a browser, refreshed. Over and over and over.

This means that if you make the same GET again, you will insert into your database again.

Consider what this may mean if the GET becomes a link and it gets crawled by a search engine. You will have your database full of duplicate data.

I also suggest reading URIs, Addressability, and the use of HTTP GET and POST.

share|improve this answer
Many, many, many tools, utilities, web crawlers and other thingamajiggies assume that GET will never be a destructive action (rightly so, since it's specified this way). If you now break your application by breaking that specification, you'll get to keep both parts of your application. –  Joachim Sauer Mar 1 '13 at 12:21
@NimChimpsky: it does get changed by a GET. That advice is simply wrong. Safe means that the user cannot be held accountable for side-effects, not that there can't be side-effects. Otherwise you couldn't have log files for your server, which would be absurd! This is spelled out quite clearly in section 9.1.1 of RFC2616. –  Jörg W Mittag Mar 1 '13 at 14:35
@JörgWMittag: I wouldn't say "simply wrong", I'd say "phrased inperfectly". A GET should not have a change as it's goal. Of course you're allowed to count, log and observe a GET request. But it should not modify your actual business data. –  Joachim Sauer Mar 1 '13 at 14:54
@NimChimpsky A GET shouldn't change the resource requested by the GET, but that doesn't mean 'nothing on the server should change'. Of course things like logs, counters, and other server state may change during any request. –  Eric King Mar 1 '13 at 14:55
Quite some years ago, Google released a browser add-on (iirc) that would pre-fetch pages via links. This also happened on some control panels that were designed poorly - the URLs would cause a record or something to be written or even deleted on the server (think post?action=delete). This caused actions to be executed without the user knowing it. Google discontinued that addon for that reason, iirc, even if it was the webapp manufacturer's fault for using GETs to change state. –  Cthulhu Mar 1 '13 at 15:41
show 4 more comments

Each HTTP verb has it's own responsibility. For example GET, as defined by RFC

means retrieve whatever information (in the form of an entity) is identified by the Request-URI.

POST, on the other hand, means insert or more formally

entity enclosed in the request as a new subordinate of the resource
identified by the Request-URI in the Request-Line

Reasons for keeping it this way:

  • It's very simple and works on the global Internet scale since 1991
  • Stick to the single responsibility principal
  • Other parties use GET to act as means of information retrieval and data mining
  • GET is assumed to be a safe operation that never modifies the state of the resource
  • Security considerations, GET is effectively a read, whereas POST is effectively a write
  • GET is cached by browsers, nodes in the network, Internet Service Providers
  • Unless the content changes, GET to the same URL must return same results to all the users or else you you won't have any trust what so ever in the returned result

For completeness and just to enforce correct usage (source):

  • GET parameters are passed as part of the URL, which is of small and limited length of 256 chars by default, with some servers supporting 4000+ chars. If you want to insert a long record, there is no legitimate way to pass this data in
  • W̶h̶e̶n̶ ̶u̶s̶i̶n̶g̶ ̶s̶e̶c̶u̶r̶e̶ ̶c̶o̶n̶n̶e̶c̶t̶i̶o̶n̶,̶ ̶s̶u̶c̶h̶ ̶a̶s̶ ̶T̶L̶S̶,̶ ̶U̶R̶L̶ ̶i̶s̶ ̶n̶o̶t̶ ̶g̶e̶t̶t̶i̶n̶g̶ ̶e̶n̶c̶r̶y̶p̶t̶e̶d̶,̶ ̶h̶e̶n̶c̶e̶ ̶a̶l̶l̶ ̶t̶h̶e̶ ̶p̶a̶r̶a̶m̶e̶t̶e̶r̶s̶ ̶o̶f̶ ̶̶G̶E̶T̶̶ ̶a̶r̶e̶ ̶t̶r̶a̶n̶s̶f̶e̶r̶r̶e̶d̶ ̶p̶l̶a̶i̶n̶ ̶t̶e̶x̶t̶. URL is actuall encrypted with TLS, so TLS is fine.
  • Inserting binary data or non-ascii characters using GET is impractical
  • GET is re-executed if a user presses a Back button in a browser
  • Some older crawlers may not index URLs with a ? sign inside
share|improve this answer
Are you sure that the URL is unencrypted over TLS? I was under the impression that the SSL/TLS handshakes occur prior to the HTTP headers being transferred. This is the reason why virtual hosting HTTPS sites over a single IP address is difficult. Am I mistaken? –  Brandon Mar 2 '13 at 17:17
That's right, I fixed it –  oleksii Mar 2 '13 at 20:14
@Brandon Modern browsers send the host domain in the clear as part of the TLS handshake (known as server name indication), to allow hosting more than one domain per IP address. The path/query part of the url is protected by TLS. There is no difference between GET and other HTTP verbs in that regard. –  CodesInChaos Mar 2 '13 at 21:41
add comment

I think the most important reason is to protect against CSRF. To protect against CSRF you must require POST. With CSRF an can be placed on an attacker's website. When the victim access this website their browser will make a GET request to your application and your application will change data because the request came from the victim's browser and has a valid session cookie.

In the early days of the internet there were browser accelerators. These programs would start clicking links on a page to cache the content. Google Web Accelerator was one of these programs. This could wreak havoc on an application that makes changes when a link is clicked. I would make the assumption that there are still people using accelerator software.

Proxy servers and browsers will cache GET requests so when the user accesses the page again it may not send the request to your application so the user thinks they took an action, but they really didn't.

share|improve this answer
+1 Good examples. –  Matsemann Mar 2 '13 at 18:01
add comment


The simplest answer is "because that's not what GET means."

Using GET to pass data for an update is like writing a love letter and sending it in an envelope marked "SPECIAL OFFER - ACT NOW!" In both cases, you should not be surprised the recipient and/or intermediaries mishandle your message.

share|improve this answer
add comment

For your CRUD operations in a database-centric application use the following schema:

Use HTTP GET for Read Operations (SQL SELECT)

Use HTTP PUT for Update Operations (SQL UPDATE)

Use HTTP POST for Create Operations (SQL INSERT)

Use HTTP DELETE for Delete Operations (SQL DELETE)

share|improve this answer
add comment

Your Answer


