What does idempotent mean for HTTP methods, and which methods are idempotent?
An idempotent request has the same effect on the server whether it is sent once or many times. GET, PUT, DELETE, HEAD and OPTIONS are idempotent; POST is not, and PATCH may not be.
Explain it simply
Pressing the lift button twice does not call two lifts; the second press changes nothing. That is idempotent. Pressing "Pay" twice on a UPI app could charge you twice if the app is careless. That is not idempotent. Idempotency is about the final state of the server, not about the response being identical.
| Method | Idempotent? | Why |
|---|---|---|
| GET | yes | only reads |
| PUT | yes | setting the same value twice gives the same state |
| DELETE | yes | the item is gone after the first call; later calls find nothing |
| POST | no | each call can create a new record |
| PATCH | depends | "set x = 5" yes, "add 5 to x" no |
DELETE may return 204 the first time and 404 afterwards, but the server state is the same.
Example
Networks fail, and clients retry. To make a POST such as a payment safe, many APIs accept an idempotency key:
app.post("/payments", async (req, res) => {
const key = req.get("Idempotency-Key");
if (!key) return res.status(400).json({ error: "Idempotency-Key required" });
const saved = await Payment.findOne({ key });
if (saved) return res.status(200).json(saved.result); // replay, no second charge
const result = await chargeCard(req.body);
await Payment.create({ key, result });
res.status(201).json(result);
});What to say in the interview
"Idempotent means repeating the request leaves the server in the same state. GET, PUT and DELETE are; POST is not. For retry-prone POSTs like payments, I use an idempotency key stored on the server."
Common mistakes
- Assuming DELETE is not idempotent because the second call returns 404.
- Letting a client retry a non-idempotent POST without protection.