Hacker News new | ask | show | jobs
by 33degrees 2412 days ago
Idempotent means that a given request always has the same result. This GET request fits that definition, since making the same request several times will always return the same thing. The fact that it modifies data means that it’s not safe, but that is a different concern. Remember that PUT and DELETE are also idempotent
1 comments

Of course it's not just that it returns the same result, but that the request has the same effect. This is not entirely true since the modification date will change, but other than that it's true that setting a key to the same value multiple times is idempotent.
If the modification date is changed, then its idempotency is open to application-specific definition.[1]

One way you might call modification time changes idempotent is if you don't care about modification times.

Another way is much subtler: Although an updated modification time represents a change, the point of HTTP idempotent requests is that repeating them automatically is harmless. This matters because some requests may be repeated automatically by some clients under some network conditions.[2] Updating the modification time twice to a near-current timestamp might satisfy the idempotency condition for the purposes of the application.

[1] This isn't as handwavy as it sounds. It means that because it's the application that determines whether the effects of a request count as "semantically" idempotent (or semantically safe), the application should choose the appropriate HTTP method (or "verb": GET, PUT, POST etc) for the application's needs. The application's choice of HTTP method matters because client libraries, proxies and servers perform different methods in different ways in the protocol.

[2] For example, if sent as the second or later request on a persistent HTTP/1.1 connection, just as the server closes the connection, then the client might retry any requests that are for an idempotent (or safe) method. So it may automatically retry GET, PUT and DELETE but not POST.

> One way you might call modification time changes idempotent is if you don't care about modification times.

My point exactly :)