Programming Terms: Idempotence

TL;DR

Idempotence means repeating an operation does not change the result or server state after the first application.

Briefing Cornell Notes

Briefing

Idempotence means an operation can be repeated multiple times without changing the outcome after the first application. In practical programming terms, it’s about whether “doing it again” builds on the previous result or leaves the system in the same state. That distinction matters most when designing APIs and choosing HTTP methods, because clients may retry requests and the server should ideally avoid unintended side effects.

A simple way to see the concept is to compare a function applied once versus applied repeatedly to its own output. With a Python example, a function that adds 10 to an input behaves differently depending on how many times it’s run: starting from 10, one application produces 20, but feeding 20 back into the same function produces 30. Because the result changes each time, the operation is not idempotent.

The contrast comes from operations that “stabilize” after the first run. Python’s built-in abs function illustrates this well: abs(-10) returns 10, and abs(10) returns 10 again. Reapplying abs keeps producing the same value, so the operation is idempotent. The idea isn’t limited to functions—an assignment like a = 10 is also idempotent in the sense that executing it repeatedly leaves the variable at the same value each time.

Where idempotence becomes especially relevant is HTTP. The GET method is treated as idempotent because it retrieves a resource without changing server state; reloading the same URL repeatedly returns the same representation. PUT is also considered idempotent in typical usage because it updates a resource to a specified value. If a client repeatedly sends “set user to Cori,” the resource ends up in the same state after the first request, and subsequent identical PUTs don’t keep modifying it.

POST, by contrast, is not idempotent because it’s commonly used for actions that change data in the background. A voting endpoint is a classic example: each POST request can record a new vote, so repeating the request can produce a different outcome (for instance, casting another vote up or down).

DELETE is often described as idempotent even though it may return different responses like 404 after the resource is gone. The key is server state: once the user is deleted, further DELETE calls don’t change anything beyond the first successful deletion. After the first call, the system remains in the same state, which is why DELETE is categorized as idempotent.

A useful rule of thumb from the examples: the first application may change the value (like turning -10 into 10), but repeated applications should not keep moving the result forward. When operations are idempotent, retries and repeated calls become safe and predictable—especially in web APIs.

Cornell Notes

Idempotence is the property of an operation where repeating it does not change the result or server state after the first application. In the transcript’s examples, a function that adds 10 is not idempotent because applying it repeatedly keeps increasing the value (10 → 20 → 30). Python’s abs is idempotent because once the number is non-negative, applying abs again leaves it unchanged (abs(-10) = 10, abs(10) = 10). In HTTP, GET and PUT are treated as idempotent because they retrieve data or set a resource to a specific value without further changes. DELETE is also idempotent because after the resource is removed, additional deletes don’t change the server state further.

How can you test whether a function is idempotent using the “apply it twice” idea?

Pick an input X, compute f(X), then compute f(f(X)). If f(f(X)) equals f(X) (the result doesn’t change after the first application), the operation is idempotent. In the example, add 10 gives f(10)=20, but applying again gives f(20)=30, so it fails the idempotence check.

Why is abs considered idempotent while “add 10” is not?

abs(-10) returns 10, and abs(10) returns 10 again—so once the output reaches a stable form, repeating the operation doesn’t change it. By contrast, add 10 keeps building on the previous result: 10 → 20 → 30, so each additional application changes the outcome.

Can idempotence apply to non-function code like assignments?

Yes. The transcript notes that a statement such as a = 10 is idempotent in practice: running it repeatedly leaves a at 10 each time. The key is that re-executing the same operation doesn’t accumulate additional changes after the first run.

Why is GET idempotent in HTTP?

GET is idempotent because it’s designed to retrieve a resource without changing server state. Reloading the same URL should return the same resource representation each time, since nothing is being modified on the server.

Why is PUT idempotent but POST is not?

PUT is typically idempotent because it updates a resource to a specified value; sending the same update repeatedly leaves the resource in the same state after the first request. POST is not idempotent because it’s commonly used for actions that create or change data each time—like a voting endpoint where each request can record another vote and produce a different outcome.

How can DELETE be idempotent even if it might return 404 on later calls?

Idempotence is about server state, not necessarily the exact response code. After the first successful deletion, the resource no longer exists; repeating DELETE doesn’t change anything further. Even if subsequent calls return 404, the server state remains unchanged, matching the idempotence definition.

Review Questions

Give an example of an operation that is not idempotent and show the difference between f(X) and f(f(X)).
Explain why PUT can be idempotent even though it changes data, while POST is generally not idempotent.
In your own words, distinguish “idempotent result” from “idempotent server state,” using DELETE as the example.

Key Points

1
Idempotence means repeating an operation does not change the result or server state after the first application.
2
A quick test is to compare f(X) with f(f(X)); if they match, the operation is idempotent.
3
abs is idempotent because once a value is non-negative, applying abs again leaves it unchanged.
4
HTTP GET is idempotent because it retrieves data without modifying server state.
5
HTTP PUT is idempotent when it sets a resource to a specific value repeatedly.
6
HTTP POST is typically not idempotent because repeated requests can create additional changes (e.g., repeated votes).
7
DELETE is idempotent because after the first deletion, further deletes don’t change server state even if responses differ (like 404).

Highlights

Adding 10 repeatedly (10 → 20 → 30) demonstrates a non-idempotent operation because each application keeps changing the outcome.

abs(-10) = 10 and abs(10) = 10 show idempotence: once stabilized, repeating the operation doesn’t alter the result.

GET and PUT are treated as idempotent in HTTP because they don’t keep changing state with repeated identical requests.

POST is not idempotent in common use because repeated calls can keep producing new effects (like casting multiple votes).

DELETE is idempotent by server-state logic: after the resource is gone, additional deletes don’t change anything further.

Topics

Idempotence
HTTP Methods
Python Functions
Server State
API Design

Mentioned

Corey Schafer
HTTP