idempotent
termprogrammingweb dev
An operation that has the same effect whether you run it once or many times.
Idempotency matters wherever retries happen: a duplicated payment request must not charge twice, a repeated deploy must not corrupt state. Designing operations to be idempotent is what makes distributed systems safe to retry.
An idempotent operation produces the same result whether applied once or many times, which is what makes retrying safe. In HTTP, GET, PUT and DELETE are specified as idempotent and POST is not, which is why a browser warns before resubmitting a form and why a client library will retry one and not the other.
The property matters most where delivery is uncertain. A network timeout does not tell you whether the request arrived, so a client that cannot retry safely has to choose between duplicating an action and abandoning it. The usual construction is an idempotency key supplied by the caller, which lets the server recognise a repeat and return the original result rather than performing the work twice, and it is the standard answer for payment and provisioning APIs.
Also known as: idempotency, idempotence