Idempotency

In most contexts, the point of an idempotent operation is that it has no additional effect if it is done more than once.

In general, in machines

For a tactile example, consider an industrial machine has an separate 'on' and a separate 'off' button.

Regardless of the state before, if you press the 'on' button, it is going to be on afterwards

Regardless of the state before, if you press the 'off' button, it is going to be off afterwards

...also regardless of how often you press that same button afterwards.

In comparison, the power button on most computers toggles (and is only a request to change - unless held for 4 seconds as per ATX specs)

...so you won't know entirely for sure about its state afterwards

so it's not idempotent.

(the fact that that's because action depends on the current state just happens to be the main reason, not a defining part of this non-idempotency)

Stoplight crosswalk buttons are idempotent (with few exceptions)

in that you can press them more than once, but it'll just stay in 'requested' mode until the system acts on it.

(and sometimes nullipotent, meaning the light will schedule you regardless of whether you pressed, and it's there just to make you feel in control)

• elevator call and floor buttons are idempotent (with few exceptions)

...even if people like to hold on to their magical thinking about special modes that make it go faster

In math, in computing

In math and computing, you're saying the output doesn't change if called more than once (with the same input parameters).

For example

• anything that makes no changes

e.g. HTTP GET, HEAD, OPTIONS, TRACE

though people do abuse GET (e.g. allowing sets from GET requests, not just POST, is moderately common)

• adding or removing an item to a set

e.g. HTTP DELETE

• various string operations, e.g. uppercasing a string

...and may more than we usually don't name specifically.

Such a property happens to be useful, in design, and in talking about design, in particular APIs, because you're typically modeling what should happen on the other end, and are usually not inspecting or policing every step.

Say, it's really useful to know that if an identical operation is sent to a server several times, it leaves the server in the same intended state.

Around updating state, this can e.g. simplify complex state management to 'just retry until is says OK'.

For the HTTP examples,

It's just defined that way so that HTTP clients can assume certain things.

it's not that you can't break that, by mistake or even by choice. In particular GET is sometimes not idempotent in practice.