Faux Idempotency | Hacker News Reader

Faux Idempotency

paperless.blog

22 pointsl0b013 comments

Is this a typical definition of idempotency? One where you have to be idempotent even when another system is in play? I wouldn't expect anything to be idempotent if something else can come along and change arbitrary state.

No REST endpoint is idempotent because I can go unplug all the servers.

Or the DNS could change and the endpoint could be called on another server

Or your authorization could change and you no longer have access to the resource.

Honestly I'm not sure what the author thinks idempotency is.

No, it is not. Typically an operation is considered idempotent if you can perform it multiple times in a row, with no other intervening operations, and the result is the same as if you had only performed the operation once. I don't know what this person is trying to get at.

Usually I’ve seen it defined as that the intended effect happens at most once. e.g. see https://developer.mozilla.org/en-US/docs/Glossary/Idempotent

From your link:

> An HTTP method is idempotent if an identical request can be made once or several times in a row with the same effect while leaving the server in the same state.

Which is according to what OP wrote.

I wouldn't translate this into "the intended effect happens at most once", as that behavior includes the effect of the transport. "at most once", "at least once" and "exactly once" are messaging behaviors after all, and idempotency is a method to convert an "at least once"-messaging-effect into an "exactly once"-change-effect.

You're absolutely right, thank you! I've posted a correction.

In simple mathematical terms idempotency is A such that AA=A.

Let X be the action "all your servers crashed and were deleted". The piece is saying that AXA is not necessarily A.

Indeed.

Faux idempotency exists, but this blog post does not illustrate it.

The post-condition of "touch file.txt" is to "make sure that file.txt exists and is writeable by user". As long as the command succeeds, that post-condition will be true. This makes command idempotent. Note that a bad permission, FS errors, or even running out of disk space will cause the command to fail. This is fine, idempotency talks about what happens if operation was applied. If it could not be applied, no promises are made.

Yes, ">>" is generally not idempotent except some circumstances. You can make an idempotent system out of it, but you have to be careful. Nothing "faux" there.

The same rules deal with limited resources -- there are no guarantees your tests may run, only that if they do run, they run in identical way.

For the record, `>> file.txt` will create a file if it doesn’t exist, won’t affect the file contents, and won’t affect modified or access times.

Google cache, as the site is having trouble for me at the moment:

http://webcache.googleusercontent.com/search?q=cache:_QnG_r4...

Obviously GET is not idempotent because as we see, the state can change if called repeatedly /s

GET supposed to be nullipotent[1] and safe[2].

It can also be implemented as a pure function without side-effects if you provide current time as a query parameter.

Reliable communication over the network and availability issues are different concerns. Though request idempotency can help with retries for command/mutations. Queries are usually nullipotent, so they're can be simply retried.

[1] https://en.wiktionary.org/wiki/nullipotent

[2] https://developer.mozilla.org/en-US/docs/Glossary/Safe/HTTP

Reply on news.ycombinator.com