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.

There is also a problem with link prefetching in some browsers – they will make a call to pre-fetch links, even if not indicated so by the page author.

If, say, your log out is behind a “GET”, linked from every page on your site, people can get logged out just due to this behaviour.

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

The POST method is used to request that the origin server accept the
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 principle
• 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

EDIT: Before, I said POST helps protect you against CSRF but this is wrong. I did not think this through correctly. You must require a session-scope unique hidden token in all your requests to change data to protect against CSRF.

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.

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?

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.

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)

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

That advice, and all of the answers here are wrong. Obviously I’m being overly dramatic, the other answers are excellent, but I believe the exact advice should be given as:

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

To say “never” is too extreme, and although the other answers here accurately explain why you should “rarely” do it, there are some scenarios where it is perfectly reasonable to change data with a GET. An example is a one-time use email verification link. Typically these links contain a GUID that when accessed will have to change data. If correctly implemented subsequent identical GET requests will be ignored.

This is obviously an edge case, but certainly worth noting.