4 ms·
But if you GET /posts/123 and then do it again, and in between, the author updated the post, you’d expect to get the latest version of the post, no? That doesn’
by timwis 5y ago
But if you GET /posts/123 and then do it again, and in between, the author updated the post, you’d expect to get the latest version of the post, no? That doesn’t make it non-idempotent, because your GET requests did not change the state at all.
- user3939382 5y agoMaybe the distinction is that the request (your request) is itself not responsible for the change.
- brainwipe 5y agoThis is correct. Idempotent GET should not itself change the state of the server.
- atuladhar 5y agoI'm pretty sure timwis and zinekeller in this thread (and detaro in the sibling thread) are all saying the same thing. Idempotency implies the request in question does not change the state, not that the state would not have changed because of other operations in the meantime. GET and QUERY are meant to be idempotent but whether they really are in practice depends on how they've been implemented.
- squeaky-clean 5y agoIdempotency only refers to state changes from subsequent invocations of the call. A command to add a user to the set of users that have upvoted a post would be idempotent. Because you can run it 20x and only the first call affects anything. A command to increase the upvote count for a comment by +1 would not be idempotent.
- timwis 5y agoGood point!
- tsimionescu 5y ago> But if you GET /posts/123 and then do it again, and in between, the author updated the post, you’d expect to get the latest version of the post, no? Not necessarily - plenty of systems offer no such guarantees, and the Web is by design eventually consistent [0]. This is what content expiration and various other cache control mechanisms are for - it's not always so important to get the latest version of a document. For example, the HN logo or index.html can probably be safely cached for days, since they are very unlikely to change, and even if they do, it's unlikely to have a major problem if someone only sees the new version after a few days. [0] Note that, at the extreme, due to special relativity, there is no absolute notion of "latest version" on the scale of geographically distributed computers: it's physically impossible to say if a request made in China to a server in the USA happened before or after a change on the server, if they happened close enough together - order of tens of milliseconds, an eternity in compute time.