What does "idempotent request" mean?

ReactJunior~3 min read

What "idempotence" means

Idempotence is a property of an operation where running it again gives the same result as running it once.

In other words:

"No matter how many times you call this request, the result won't change (as long as the input data is the same)."

A simple example

Say you have this endpoint:

javascript

DELETE /api/users/42

The first call deletes user id=42.
The second call: the user is already deleted, but the system's state hasn't changed (the user still doesn't exist).

So DELETE is an idempotent request.

Formally

An HTTP request is called idempotent if calling it again with the same parameters does not change the resource's state (and returns the same result).

Idempotence and HTTP methods

Method	Idempotent?	Why
GET	Yes	Fetches data, doesn't change the server
HEAD	Yes	Like GET, but without a body
PUT	Yes	"Overwrites" a resource entirely, calling it twice in a row = the same result
DELETE	Yes	After deletion, calling DELETE again changes nothing
OPTIONS	Yes	Only returns meta-information
POST	No	Every call creates a new resource (e.g. an order, a comment)
PATCH	Depends	Can be idempotent if it applies the same change repeatedly

Request examples

Idempotent requests

GET - a simple read:

javascript

GET /api/users/5

-> returns the user, doesn't change server state.

PUT - updating a resource:

javascript

PUT /api/users/5
{
  "name": "Alex"
}

-> can be called 10 times in a row, the result is the same (the user's name is "Alex").

DELETE - deleting a resource:

javascript

DELETE /api/users/5

-> deletes once, repeated calls change nothing.

Non-idempotent requests

POST - creating a resource:

javascript

POST /api/orders
{
  "productId": 10,
  "quantity": 1
}

-> every call creates a new order, so the system's state changes.

Why this matters

1. Safe request retries

If the connection drops, the client can retry an idempotent request without fear of "duplicating actions".

Example:

you call DELETE /users/42,
the network drops,
the client retries the request; the server is in the same state.

But with POST /orders, a retry can create two orders.

2. Caching

HTTP clients (browsers, CDNs, React Query, SWR) can cache idempotent requests (GET, sometimes HEAD), since they don't change state.

3. Load Balancing / Retry / Fault Tolerance

API gateways, load balancers, and libraries (Axios, React Query) often automatically retry failed requests.

Retrying is safe only for idempotent operations.

4. REST API design

REST architecture is built on the principle that:

GET, PUT, DELETE are idempotent;
POST is not idempotent;
PATCH depends on the implementation.

This makes an API predictable and safe under failures or repeated calls.

Example in code

javascript

// Not idempotent: creates a new order
await api.post('/orders', { productId: 12 });

// Idempotent: updates the order
await api.put('/orders/123', { status: 'paid' });

// Idempotent: deletes the order
await api.delete('/orders/123');

Summary

Characteristic	Idempotent request
Calling it again	Doesn't change the result
Changes state?	No (or only once)
Safe to retry	Yes
Can be cached	Yes (e.g. GET)
Example	`GET`, `PUT`, `DELETE`

In short:

An idempotent request is one that can be called many times in a row, and the system stays in the same state it was in after the first call.

It exists for safe retries, predictability, and API resilience.

Short Answer

Interview ready

Premium

A concise answer to help you respond confidently on this topic during an interview.