The Core Idea
Declaring Intent Before Acting
Every HTTP request includes a method (sometimes called a 'verb') that declares, upfront, what kind of operation the request intends to perform on the target resource — retrieving data, creating something new, replacing something entirely, updating part of something, or deleting something. This isn't just a labeling convention; browsers, caches, proxies, and well-designed APIs all rely on the declared method to behave correctly and predictably.
Two properties in particular — safety (does the request change anything on the server?) and idempotency (does making the exact same request multiple times produce the same end result as making it once?) — distinguish the methods from each other in ways that matter enormously for real-world reliability, especially when requests can be retried due to network issues.
💡 Memory Trick
Think of a library checkout desk. GET is asking to look at a book without checking it out — completely harmless, do it as many times as you want. POST is dropping off a brand-new book donation — each time you do it, a NEW book gets added, so doing it twice adds two books, not one. PUT is replacing an entire existing book with a new edition in the exact same spot — doing it once or five times leaves the exact same final book on the shelf. PATCH is just updating the book's condition tag without replacing the whole book. DELETE is removing a book from the shelf — after the first removal, doing it again has no further effect, since it's already gone.
The Five Core Methods
What Each One Actually Does
GET
Retrieve Data — Safe and Idempotent
Requests a representation of a resource without modifying anything on the server. Safe (causes no side effects) and idempotent (repeating it any number of times produces the same result as doing it once).
POST
Create Something New — Not Idempotent
Submits data to create a new resource or trigger a server-side action. NOT idempotent — sending the exact same POST request twice typically creates two separate new resources (like submitting a form twice accidentally creating two duplicate orders), not one.
PUT
Replace Entirely — Idempotent
Replaces an entire existing resource at a specific location with the provided data (or creates it at that exact location if it doesn't exist yet). Idempotent — sending the same PUT request multiple times results in the exact same final state, since each request fully overwrites with the same data.
PATCH
Update Partially — Not Necessarily Idempotent
Applies a partial modification to an existing resource, changing only specific fields rather than replacing the whole thing. Whether PATCH is idempotent depends on exactly what the patch instruction says — 'set field X to value Y' is idempotent, but 'increment field X by 1' is NOT, since repeating it changes the result each time.
DELETE
Remove a Resource — Idempotent
Removes the specified resource. Idempotent in the sense that deleting an already-deleted resource still leaves it in the same 'deleted/absent' end state — though the specific status code returned on a repeat request may differ (like a 404 the second time).
Why Idempotency Matters
Safe Retries Over Unreliable Networks
Idempotency matters enormously in practice because network requests can fail or time out in ambiguous ways — you might send a request, the server might process it successfully, but the response confirming success gets lost on the way back, leaving the client unsure whether the operation actually happened. For an idempotent method (like PUT or DELETE), the safe response is simply to retry — worst case, you're repeating an operation that produces the exact same end result.
For a non-idempotent method like POST, blindly retrying after an ambiguous failure risks creating duplicate resources (like accidentally submitting the same order twice) — this is exactly why well-designed APIs sometimes add extra safeguards (like requiring a unique 'idempotency key' the client generates) specifically for POST requests, to make otherwise-non-idempotent create operations safely retryable.
🖥️ Applied Scenario
A customer submits a payment form, their network connection briefly drops right as the request is sent, and their browser automatically retries the request without the customer noticing.
1
You identify that if the payment submission used a plain POST request with no additional safeguards, this automatic retry could genuinely charge the customer twice, since POST is not idempotent — two identical requests can create two separate payment records.
2
You recognize the fix isn't to switch to a different HTTP method (payment creation is genuinely a 'create' operation, appropriately modeled as POST), but to add an idempotency key: a unique identifier the client generates once and includes with the request.
3
The server checks whether it has already processed a request with that exact idempotency key — if so, it simply returns the original result again rather than processing a second, duplicate charge.
4
Conclusion: this pattern makes an inherently non-idempotent POST operation safely retryable, directly addressing the real risk that network retries pose specifically because of POST's lack of built-in idempotency.
📌 Exam Application
Exam questions frequently ask you to identify the appropriate HTTP method for a described operation, and to state whether that method is safe and/or idempotent. You may also be asked to explain why idempotency specifically matters for handling network retries, and to identify a scenario where a non-idempotent method could cause a real problem if retried carelessly.
⚠️ Most Common HTTP Methods Mistakes
The most common mistake is assuming PATCH is always idempotent the way PUT is — PATCH's idempotency actually depends entirely on the semantics of the specific partial update being described; 'set status to complete' is idempotent, but 'append this item to the list' or 'increment the counter' are not, since repeating them changes the result further each time. Another frequent error is confusing 'safe' with 'idempotent' — GET is both safe (no side effects at all) and idempotent, but DELETE is idempotent (repeating it leaves the same end state) while clearly NOT safe (it does have a real side effect — actually deleting something).
✓ Quick Self-Test
Can you state, for each of GET, POST, PUT, PATCH, and DELETE, whether it is safe and whether it is idempotent? Can you explain, using the payment retry scenario, why idempotency matters specifically for handling unreliable network conditions?
→
← All Networking Lessons