3 ms·

I think you have misunderstood slightly. GET, for example, is an idempotent method [1], which means "the intended effect on the server of multiple identical re

I think you have misunderstood slightly. GET, for example, is an idempotent method [1], which means "the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request." However, it is NOT true that sending the same GET request at different points in time would have the same effect - if a resource is deleted or moved, you might get a 404, 301 or 200 where previously you got something else. When idempotence is talked about in these RFCs there's an implied caveat that the "multiple requests" they talk about happen at the same time, under the same network conditions. I think that's what they mean by "identical". [1] https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.2 https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.2

lilyball 5y ago
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?

lilyball 5y ago

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?