> 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.
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.
Let X be the action "all your servers crashed and were deleted". The piece is saying that AXA is not necessarily A.
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.
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.