Why is using HTTP GET to update the state on the server in a RESTful call incorrect?

Question

OK, I already know all the reasons on paper why I should not use HTTP GET when calling RESTful to update the status of something on the server. Thus, each time, possibly returning different data. And I know that this is wrong for the following “on paper” reasons:

• HTTP GET calls must be idempotent
• N> 0 calls should always get the same data back
• Violates the HTTP specification
• HTTP GET call is usually read-only

And I'm sure there are more reasons. But I need a concrete simple example to justify, except “Well, this violates the HTTP Spec!” .... or at least I hope so. I have also read the following, which are more consistent with the above list: Does RESTful break when I write stuff on the server when GET is called? and HTTP POST with URL request parameters - is it a good idea or not?

For example, can someone justify the above and why it is wrong / incorrect to use / incorrectly use HTTP GET with the following RESTful call

"MyRESTService/GetCurrentRecords?UpdateRecordID=5&AddToTotalAmount=10" 

I know this is wrong, but hopefully this will help give an example to answer my original question. So the above will update recordID = 5 with AddToTotalAmount = 10 and then return the updated records. I know that POST should be used, but let me say that I used GET.

How exactly and answer my question, can this really cause a real problem? Like all violations from the above list of tokens, how to use HTTP GET to perform the above actions, there is some real problem? Too many times I enter a scenario where I can justify things with the words “Because the dock said so,” but I need a rationale and a better understanding of this.

Thanks!

Answer 1

The practical case when you encounter a problem is that the HTTP GET is often repeated in the event of a failure in the implementation of HTTP. Thus, in real life, you can get situations when the same GET receives the server several times. If your update is idempotent (this is yours), then there will be no problem, but if it is not idempotent (for example, adding some value to the amount, for example), you can get several (unwanted) updates.

HTTP POST never repeats, so you will never have this problem.

Answer 2

If any form of search engine robots on your site can inadvertently change your data.

This happened in the past with Google Desktop Search, which caused people to lose data because people implemented delete operations like GET.

Answer 3

This is an important reason that GETs should be idempotent and not used to update server state in relation to Cross-Site Request Forgery Attacks. From the book: Professional ASP.NET MVC 3

Idempotent GET
The big word, of course, but it's a simple concept. If the operation is idempotent, it can be performed several times without changing the result. In general, a good rule of thumb is that you can prevent a whole class of CSRF attacks by only changing the situation in your DB or on your site using POST. This means registration, logout, login, etc. At the very least, this limits the confusing of several opponents.

Answer 4

I think reading this resource: http://www.servicedesignpatterns.com/WebServiceAPIStyles can help you distinguish between the message API and the api resource?