Can I do that again?
Two properties govern how HTTP methods behave when things go wrong on the network: safety and idempotency. Understanding these is essential for building reliable systems.
Safe methods are those that do not modify any server-side state. They are read-only. GET and HEAD are safe. A client can call them freely without worrying about side effects.
Idempotent methods are those where performing the operation multiple times produces the same result as performing it once. The server ends up in the same state regardless of how many times the request is sent.
| Method | Safe? | Idempotent? |
|---|---|---|
| GET | ✅ Yes | ✅ Yes |
| HEAD | ✅ Yes | ✅ Yes |
| PUT | ❌ No | ✅ Yes |
| DELETE | ❌ No | ✅ Yes |
| POST | ❌ No | ❌ No |
| PATCH | ❌ No | ❌ No* |
PATCH can* be designed to be idempotent, but it is not guaranteed by the spec.
Why this matters in practice: When a network request fails, you don't always know whether the server received it. If the method is idempotent, it is safe to retry automatically — the worst case is a duplicate request that produces no additional effect. If the method is not idempotent (like POST), retrying blindly can cause duplicate records, duplicate charges, or duplicate emails.
This is why your browser shows a warning when you try to refresh a page after a form submission: "Are you sure you want to resubmit this form?" The browser knows the original request was a POST and that retrying it might have unintended consequences.
In distributed systems, load balancers and service meshes use idempotency to decide whether to automatically retry failed requests. A well-configured retry policy will retry GET and PUT freely but will be much more conservative with POST.
Interviewers frequently ask: "What is the difference between PUT and PATCH?" The precise answer: PUT replaces the entire resource — if you omit a field, it gets deleted or reset to a default. PATCH applies a partial update — only the fields you send are changed. A follow-up question is often: "Is PATCH idempotent?" The honest answer is: not necessarily. PATCH /counter {"increment": 1} is not idempotent because each call changes the value. But PATCH /user/42 {"email": "[email protected]"} is idempotent because applying it ten times leaves the email the same.