Repeating an operation need not add another effect
Setting a configuration to a chosen value differs from incrementing a counter again: repetition can preserve the same target state in the first case while adding another change in the second. Idempotence therefore depends on the specified effect, not merely identical request bytes.
HTTP defines an idempotent method through the intended server effect of repeated identical requests. It includes PUT, DELETE, and safe methods, without requiring every request to succeed or every repeated response to have the same status.
References: [1]
Retries need to identify the same intent
A connection can fail after the server completes work but before its caller receives the response. An API avoiding duplicate creation can use a caller-provided request identifier to distinguish a retry from a separate intended operation.
Amazon’s idempotent-API account requires token recording and corresponding mutations to be coordinated atomically. Recording only the token or only the resource leaves inconsistent outcomes. A deduplication key therefore needs consistent associated state, not just a lookup name.
References: [2]
Idempotence does not make every trace identical
HTTP’s constraint concerns the requested effect, while a server can retain separate logs or revision history for each request. Avoiding an additional business effect differs from promising no repeated internal work.
Safe retry also depends on the resource and interface contract. HTTP does not treat a failed request as sufficient justification to retry a non-idempotent operation automatically. An applicable idempotence contract or reliable evidence that the original was not applied is needed.