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 not change resources on the server.

However, if a client were to come up to me today and say ‘I don’t care what The Right Way to do things is, it’s easier for us to use your API if we can just use call URLs and get some XML back – we don’t want to have to build HTTP requests and POST/PUT XML,’ what business-conducive reasons could I give to convince them otherwise?

Are there caching implications? Security issues? I’m kind of looking for more than just ‘it doesn’t make sense semantically’ or ‘it makes things ambiguous.’

Edit:

Thanks for the answers so far regarding prefetching. I’m not as concerned with prefetching since is mostly surrounding internal network API use and not visitable HTML pages that would have links that could be prefetched by a browser.

Answer 1

• 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.