Understanding Idempotent HTTP Requests: Definitions and Classification

When implementing retry mechanisms for client‑side HTTP requests, it is important to know which methods are considered idempotent. The library axios-retry retries by default only on network errors or 5xx responses for idempotent requests such as GET, HEAD, OPTIONS, PUT or DELETE.

An HTTP method is idempotent if a single request has the same effect on the server as multiple identical requests. In other words, repeating the request does not change the final state of the resource.

The article lists the classification of HTTP methods:

Safe (and idempotent) requests: GET, HEAD, OPTIONS, TRACE – these only read data and never modify server state.

Non‑idempotent requests: POST – typically creates a new resource each time it is called.

Idempotent requests: PUT – replaces a resource entirely; repeating the call leaves the resource unchanged after the first successful update.

Idempotent requests: DELETE – removes a resource; subsequent deletions have no further effect.

Conditional idempotency: PATCH – may be idempotent in some cases but generally is not, especially when it modifies auto‑incrementing fields.

Non‑idempotent request: CONNECT – establishes a tunnel; each call creates a new connection.

Example of a non‑idempotent POST request that creates a new row each time:

POST /add_row HTTP/1.1
POST /add_row HTTP/1.1   -> Adds a 2nd row
POST /add_row HTTP/1.1   -> Adds a 3rd row

In summary, the idempotent HTTP methods are GET, HEAD, PUT, DELETE, OPTIONS, and TRACE, while POST, PATCH, and CONNECT are considered non‑idempotent.