GET is idempotent because it doesn’t modify data, not because multiple GET requests will return the same response. I could make an HTTP endpoint that returns ra

GET is idempotent because it doesn’t modify data, not because multiple GET requests will return the same response. I could make an HTTP endpoint that returns random data on every request and issuing a GET to that endpoint is still considered idempotent. It’s the effect on the server that defines this property, not the effect on the client. And no, the “multiple requests” do not happen at the same time, this draft even explicitly says that MUST produce a conflict error. The assumption is the multiple requests occur in a small window of time, but the size of that window is entirely up to the server. And even a window of time measured in seconds could still cause the data to have been changed before the request is retried. For example, let’s consider a Twitter-like service. When you want to Like a post, that’s going to be a POST request. And it’s reasonable for the response to tell you the new Like count for the post. If you go to Like a popular post, and the request is retried 10 seconds later due to network timeout, that post could have gotten dozens of Likes in that time span. Surely the server should not be required to tell the client what the Like count was 10 seconds ago instead of the current count?