−The functions return new dictionaries to make the state transformations visible; they do not operate an audio device. Both are written as pure functions, but only one is idempotent. A command that writes a setting to a real device can have side effects while remaining idempotent with respect to the observed volume.
These properties answer different questions.
Property | What it compares | Example
Determinism | Does the same input produce the same result? | Integer squaring
Purity | Does the result depend only on the input, without observable side effects? | A function that computes a square
Idempotence | Does applying the operation again preserve the first result? | Absolute value; setting the volume to 20
Involution | Does applying it twice restore the original input? | Boolean negation
Negating a boolean twice restores its original value, which differs from the value after one negation. Also, an operation that happens to preserve a particular input need not be idempotent over its full domain: squaring leaves both 0 and 1 unchanged.
Communication failures give us a reason to repeat
Remote calls create a practical reason to send the same command again. If a server saves an order but its response disappears, the caller may be unable to distinguish an undelivered request from a completed request whose reply was lost. Retransmission helps recover from communication failure, but repeating an order-creation effect can create another order.
Birrell and Nelson's 1984 paper Implementing Remote Procedure Calls, section 3.2, describes call identifiers and sequence numbers for recognizing duplicate call packets. Retransmission and duplicate execution were already separate concerns in this RPC design. This is a historical example of duplicate suppression, rather than evidence that the paper invented idempotence. Publication record, paper PDF.
The 1997 HTTP/1.1 specification, RFC 2068, distinguishes safe methods from idempotent methods in section 9.1. Asking for retrieval and repeating a request without accumulating its effects are different properties. The distinction informs which requests a client can retry after a connection fails. RFC 2068 sections 8.1.4 and 9.1.
RFC 7231 in 2014 and RFC 9110 in 2022 retain this distinction. The table describes the semantics promised by the methods; using a method name still requires the server to implement that promise. RFC 7231 section 4.2.
Method | Safe? | Idempotent? | Reason
GET and HEAD | Yes | Yes | The request means retrieval
PUT | No | Yes | It specifies target resource state without accumulating repeated effects
DELETE | No | Yes | Repeating removal adds no further removal effect
POST | No | No general guarantee | The resource and application define the processing or creation semantics
A first DELETE may return 204 and a later one 404 while preserving the intended deletion effect. RFC 9110 permits per-request logging or revision history and explains that responses to idempotent requests may differ. Its comparison concerns the intended server effect. RFC 9110 section 9.2.2.
Why order creation needs a request identity
A command to add an order normally creates another order each time it runs. Such an API can identify a repeated attempt at the same operation and avoid creating its effect again.
[Image]
+These functions return new dictionaries instead of operating a volume control. Both compute a new value from their input, but only set_volume is idempotent. A command that writes to a real device can cause a side effect and still be idempotent with respect to the volume we observe.
Property | Relationship to check | Example
Determinism | Does the same input give the same result? | Squaring an integer
Purity | Does the result depend only on the input, with no observable side effect? | A function that computes a new squared value
Idempotence | Does applying it to the first result leave that result unchanged? | Absolute value; setting volume to 20
Involution | Does applying it twice restore the original input? | Boolean negation
One Boolean negation gives a different value from two. Squaring also leaves 0 and 1 unchanged but fails the idempotence law at 2. A single output, or a few inputs where the law happens to hold, cannot establish the property over the full domain.
In a real program, we must also choose the state under observation. If the program records each button press separately from the volume, repeated setting may preserve the volume while changing that larger record each time. HTTP later chose the request's “intended effect” as its comparison for a related reason.
When other commands intervene
Idempotence describes reapplying the same operation. The order of different operations is a question of commutativity. Commands to set the volume to 20 and to 50 are each idempotent, but the final volume depends on which runs last.
Composing idempotent operations does not always produce another idempotent operation. On pairs of integers, let F(x, y) = (x, x) and G(x, y) = (y + 1, y). Applying either F or G twice has the same result as applying it once. Yet repeating a sequence of F followed by G changes the pair again:
Application | State
Initial | (0, 0)
F then G | (1, 0)
Run the same pair again | (2, 1)
If two idempotent operations also commute, their composition is idempotent: expand two applications of the composition, put equal operations together by changing their order, and apply each idempotence law. When a retry repeats a whole workflow, its combined effect needs its own check.
Another user can change the state between attempts. A client sets the volume to 20, another user changes it to 50, and then the first client retries its earlier command: the volume returns to 20. The setting command remains idempotent, but preserving the other user's change requires a separate mechanism, such as a version condition or concurrency control.
Retrying when no response arrives
A client sends an order request to a server and receives no response. The connection may have failed before the server received the request, or the server may have saved the order and the response may have disappeared on its way back. Sending the request again can create the order in the first case; if the server also creates a new order in the second case, there will be two.
In §3.2 of their 1984 paper Implementing Remote Procedure Calls, Birrell and Nelson use call identifiers and sequence numbers to distinguish duplicate call packets. A caller retransmits a packet to obtain a response, and the receiver decides whether to execute the same call again. Early RPC design treated those as separate actions. Paper and publication record, paper PDF.
On the web, §9.1 of RFC 2068, the 1997 HTTP/1.1 specification, distinguishes safe methods from idempotent ones. It separates a client's request to retrieve information from a request whose effect does not accumulate when sent again. The distinction helps a client decide which requests it can retry automatically after a broken connection. RFC 2068 §§8.1.4 and 9.1.
RFC 7231 in 2014 and RFC 9110 in 2022 retain the distinction. The table describes method semantics; server implementers must make their code preserve those effects across repeated requests. RFC 7231 §4.2.
Method | Safe? | Idempotent? | Why
GET and HEAD | Yes | Yes | The client requests retrieval
PUT | No | Yes | It specifies the state of the target resource
DELETE | No | Yes | It removes the association with the target
POST | No | No general guarantee | The resource and application define what creation or processing means
PATCH | No | No general guarantee | Repeated effects depend on the change and its format
RFC 5789 defined PATCH for partial modification in 2010 and explains that a particular PATCH request can be constructed to be idempotent. Assigning the value 20 and adding 1 to the current value have different effects when repeated, even though both are partial modifications. For changes dependent on a base version, it recommends conditions such as a strong ETag with If-Match. RFC 5789 §2.
A first DELETE can return 204 and a later DELETE 404 while the intended deletion effect remains the same. RFC 9110 allows per-request logs or history and notes that responses may differ. The client compares the server effect intended by the request. RFC 9110 §9.2.2.
Another user may change a resource between two GET requests, so their responses can differ too. Whether a response can be stored and reused depends separately on cacheability and freshness rules. That is why safety, idempotence, and cacheability have separate names. RFC 9110 §§9.2.1 and 9.2.3.
Request keys distinguish attempts at one order
If a server creates a new order every time a client says to add one, a retry creates another order. The client and server first need a rule for which requests count as attempts at the same operation.
[Image]
