What's the difference between safe and idempotent in HTTP methods?

Safe and idempotent answer different questions. A safe method changes nothing observable; an idempotent method may change things, but a second identical call leaves the state the same as after the first. Every safe method is idempotent, but many idempotent methods are not safe.

Say the state before a call is $S_0$, after one call is $S_1$, and after two identical calls is $S_2$. Safe means $S_1=S_0$. Repeatable, which is what HTTP calls idempotent, means $S_2=S_1$. The second condition is weaker: it allows $S_1$ to differ from $S_0$, provided the second call does not move the state again.

The natural guess is that idempotent means harmless, or that safe and idempotent are two words for the same property. Neither holds. A delete changes the world: the first call removes the thing. A second identical delete finds nothing to remove, but the state afterwards is the same as after the first call. That is idempotent with a real side effect.

The other half of the mistake is thinking the response has to be the same. It does not. The first delete may return 204 and the second 404. Idempotency is about the state left behind, not the status line. Confusing the two makes people reject the correct classification of delete, and then they design retry logic around the wrong property.

Take a balance of 100 and an operation that adds 50. One call gives 150. A second identical call gives 200, not 150, so the operation is not repeatable. Now wrap the same movement in a transfer record whose identifier the caller supplies, say transfer 7. The first call records transfer 7 and moves the balance from 100 to 150. The second call arrives with transfer 7, finds it already recorded, returns the existing record, and leaves the balance at 150. The side effect remains: money moved once. What changed is that the operation now names a thing rather than describing a movement, so a duplicate request lands on the existing thing.

A replace is repeatable for the same reason in a simpler form. If order 7 is {a,b} and the caller sends {x}, the first call leaves {x}; the second writes {x} over {x}. The state after two calls is the state after one. The caller may retry after a timeout without asking the server what happened, because both possible histories, one call or two, end at {x}.

A create where the server chooses the identifier is the opposite case. With zero orders, the first call makes order 101 and the count is one. The second call makes order 102 and the count is two. The state after two calls is not the state after one, so a timeout leaves the caller choosing between a missing order and a duplicate. Moving the identifier to the caller changes the count from 0 to 1 to 1.

Safe does not mean the call has no cost or no trace. A read may write a log line, increment a counter, or be slow enough to matter. The property is about the resource state the caller depends on, not about every byte the server writes. If your definition of observable includes those traces, almost nothing is safe.

Idempotency is also defined for the same request repeated. It does not by itself make two simultaneous copies safe. Two requests carrying transfer 7 at the same instant can both look up the record, both find nothing, and both insert unless a uniqueness constraint or a transaction makes one of them lose. The sequential definition says the second call after the first is harmless; it does not say two calls in parallel are harmless. The fix is a uniqueness rule on the identifier, not a retry policy.

There is a class that resists the move entirely: effects outside your system that you cannot inspect, such as an email already sent or a payment already handed to another organisation. For those, repeatability has to come from a record of the attempt on your side, checked before the external effect is triggered.

The practical rule is not 'safe means no side effects'. It is: safe methods may be replayed and cached without asking; idempotent methods may be replayed after a timeout because the state converges; everything else needs a caller supplied key or a query before retry. The classification decides who may retry, not how dangerous the operation sounds.