Idempotency vs Safety
Fast recall
Quick revision
Core answer
GET is both safe and idempotent, while PUT and DELETE are idempotent but unsafe because they intentionally change server state.Interview-ready guide
Interview answer
Safety and idempotency describe different parts of an HTTP method's contract. Safety asks whether the client requested a change to application state. Idempotency asks whether repeating the identical request changes the intended effect after its first application. A method can therefore be idempotent without being safe: it can deliberately change state once and still have a repeatable final effect.
GET, HEAD, OPTIONS, and TRACE are safe because their defined semantics are essentially read-only. A server may still append an access log, record a metric, or fill a cache while handling a GET. Those incidental effects do not make the method unsafe because the client did not request them. A route such as GET /orders/42?cancel=true is different: cancellation is the requested effect and violates GET's safety contract.
PUT and DELETE are idempotent but not safe. Repeating the same PUT /profiles/42 representation asks for the same replacement state. Repeating DELETE /files/42 keeps the target association absent. Both operations intentionally change server state, so neither is safe, but the second identical request does not ask for another distinct final effect.
Every safe method is also idempotent. PUT and DELETE add the idempotent-but-unsafe group. POST and PATCH have neither guarantee in their general method semantics, although a particular POST can use an idempotency key and a particular PATCH operation can be repeatable. The method supplies a shared default, and the endpoint implementation still has to honor that contract.
Safety lets browsers, crawlers, link checkers, and prefetchers follow links without triggering a business action. Idempotency lets a client retry more confidently when a connection fails before the response arrives. Neither property bypasses authorization or guarantees that a retry will succeed, return the same status, or avoid concurrent-update conflicts. They describe request intent and repeatability, not every operational result.
Idempotency vs Safety
Direct Answer
Safety means the client is asking only to read or observe, not to change application state. Idempotency means repeating the same request has the same intended effect as making it once. GET is both safe and idempotent, while PUT and DELETE are idempotent but unsafe because they intentionally change server state.
Deep Dive & Architecture
Use two separate tests. First ask, “Did the client request an application-state change?” If no, the semantics are safe. The server can still write an access log or update a cache because the caller did not ask for those effects. A route such as GET /orders/42?cancel=true fails this test: cancellation is the requested action, so putting it behind GET breaks GET's shared meaning.
Next ask, “After the first application, does the same request ask for another intended change?” Replacing a profile with the same representation does not; appending another event does. This is the idempotency test. A request can be slow, fail authorization on a later attempt, or return different metadata and still be idempotent.
The practical difference appears when software acts automatically. Browsers, crawlers, link previews, and caches may issue a safe method without asking the user. Clients and intermediaries can retry an idempotent request after a connection failure because repeating it should not add another requested effect. An unsafe GET may trigger work unexpectedly; a blindly retried non-idempotent POST may create duplicate work.
The method gives the standard default, but the implementation must honor it. An endpoint can promise more: a POST can define operation-key behavior, and a particular PATCH can be designed to set a value repeatedly. That stronger promise belongs in the API contract; it does not change the general semantics of every POST or PATCH.
Code Example
GET /orders/42?cancel=true HTTP/1.1
Host: api.example.com
POST /orders/42/cancellation HTTP/1.1
Host: api.example.com
Content-Type: application/json
Idempotency-Key: cancel-order-42-v1
{"reason": "customer_request"}
The POST remains unsafe because it requests cancellation. The application key can give that particular operation retry protection; it does not make POST safe.
Check your understanding
Answer these without looking back at the article.
- Why is DELETE idempotent but not safe?
- Can a safe request write to an access log?
- Why is a destructive action behind GET risky?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.