Suggest an editImprove this articleRefine the answer for “What does "idempotent request" mean?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)**Idempotence** is a property of an operation where repeating it produces the same result as running it once: no matter how many times you call such a request, the result stays the same as long as the input is the same. **Key point:** in REST, `GET`, `PUT`, `DELETE`, and `HEAD` are idempotent, `POST` is not (every call creates a new resource), and `PATCH` depends on the implementation - and it's exactly idempotence that makes it safe to retry requests after network failures.Shown above the full answer for quick recall.Answer (EN)Image## 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**.For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.