Why shouldn't data be modified on an HTTP GET request?

Question

I know that using non-GET methods (POST, PUT, DELETE) to modify server data is The Right Way to do things. I can find multiple resources claiming that GET requests should no

Answer 1

Security for one. What happens if a web crawler comes across a delete link, or a user is tricked into clicking a hyperlink? A user should know what they're doing before they actually do it.

Answer 2

I'm kind of looking for more than just "it doesn't make sense semantically" or "it makes things ambiguous."

...

I don't care what The Right Way to do things is, it's easier for us

Tell them to think of the worst API they've ever used. Can they not imagine how that was caused by a quick hack that got extended?

It will be easier (and cheaper) in 2 months if you start with something that makes sense semantically. We call it the "Right Way" because it makes things easier, not because we want to torture you.

Answer 3

• Prefetch: A lot of web browsers will use prefetching. Which means that it will load a page before you click on the link. Anticipating that you will click on that link later.
• Bots: There are several bots that scan and index the internet for information. They will only issue GET requests. You don't want to delete something from a GET request for this reason.
• Caching: GET HTTP requests should not change state and they should be idempotent. Idempotent means that issuing a request once, or issuing it multiple times gives the same result. I.e. there are no side effects. For this reason GET HTTP requests are tightly tied to caching.
• HTTP standard says so: The HTTP standard says what each HTTP method is for. Several programs are built to use the HTTP standard, and they assume that you will use it the way you are supposed to. So you will have undefined behavior from a slew of random programs if you don't follow.

Answer 4

Good reasons to do it the right way...

They are industry standard, well documented, and easy to secure. While you fully support making life as easy as possible for the client you don't want to implement something that's easier in the short term, in preference to something that's not quite so easy for them but offers long term benefits.

One of my favourite quotes

Quick and Dirty... long after the Quick has departed the Dirty remains.

For you this one is a "A stitch in time saves nine" ;)

Answer 5

How about Google finding a link to that page with all the GET parameters in the URL and revisiting it every now and then? That could lead to a disaster.

There's a funny article about this on The Daily WTF.

Answer 6

GETs can be forced on a user and result in Cross-site Request Forgery (CSRF). For instance, if you have a logout function at http://example.com/logout.php, which changes the server state of the user, a malicious person could place an image tag on any site that uses the above URL as its source: http://example.com/logout.php. Loading this code would cause the user to get logged out. Not a big deal in the example given, but if that was a command to transfer funds out of an account, it would be a big deal.