HTTP Methods Deep Dive — GET, POST, PUT, DELETE, PATCH Semantics
Fast recall
Quick revision
Core answer
Whether the candidate knows the semantic meaning of each method beyond simple CRUD mapping.
Using POST for everything — losing idempotency guarantees, caching, and clear API semantics.
Explain safety (GET doesn't modify state) vs idempotency (PUT can be retried safely), and mention that POST tunneling (using POST for everything) is a REST anti-pattern.
Interview-ready guide
Interview answer
HTTP methods are not just routing conventions — they carry semantic contracts about idempotency, safety, and caching that clients, proxies, and CDNs rely on.
The four dimensions
- Safe — no server-side state change: GET, HEAD, OPTIONS
- Idempotent — same server state on repeated calls: GET, HEAD, OPTIONS, PUT, DELETE
- Cacheable — responses may be cached: GET, HEAD (by default), POST with explicit headers
- Request body allowed — semantic convention: POST, PUT, PATCH (yes); GET, DELETE (technically allowed but semantically undefined)
Decision guide
- Retrieve a resource or collection → GET
- Create a new resource (server assigns ID) → POST
- Replace a resource completely (client knows ID) → PUT
- Partially modify a resource → PATCH
- Remove a resource → DELETE
- Discover available methods (CORS preflight) → OPTIONS
Common mistakes
- POST for everything: loses idempotency and cacheability signals for clients and CDNs
- GET with a request body for complex search: use POST to
/orders/searchwith a request body for complex filter criteria — GET body is semantically undefined - DELETE that is not idempotent: throwing
404on the second call is fine; the state (resource gone) is the same
HTTP Methods Deep Dive — GET, POST, PUT, DELETE, PATCH Semantics
Direct Answer
Each HTTP method maps to a CRUD operation with specific semantics: GET retrieves (safe, idempotent, cacheable), POST creates (not idempotent), PUT replaces entirely (idempotent), PATCH modifies partially (idempotency depends on operation), DELETE removes (idempotent). Using methods correctly enables caching, safe retries, and clear API semantics.
Code Example
# --- GET: read a resource (safe, idempotent, cacheable) -----------------------
curl -s https://api.example.com/v1/orders/42
# -> 200 OK with the order JSON
# Conditional GET (cache revalidation)
curl -s https://api.example.com/v1/orders/42 \
-H 'If-None-Match: "v3"'
# -> 304 Not Modified (no body)
# --- POST: create a resource (not idempotent unless you add Idempotency-Key) --
curl -X POST https://api.example.com/v1/orders \
-H 'Content-Type: application/json' \
-H 'Idempotency-Key: 7a9c3f12-b4e8-4e0a-9f77-0b3a8c2d1e55' \
-d '{ "sku": "ABC-123", "qty": 2 }'
# -> 201 Created
# Location: /v1/orders/ord_abcd
# --- PUT: full replacement (idempotent) ---------------------------------------
curl -X PUT https://api.example.com/v1/orders/42 \
-H 'Content-Type: application/json' \
-H 'If-Match: "v3"' \
-d '{ "id": 42, "sku": "ABC-123", "qty": 3, "status": "paid" }'
# -> 200 OK (or 204 No Content). Same body twice = same state.
# --- PATCH: partial update (idempotency not guaranteed) -----------------------
curl -X PATCH https://api.example.com/v1/orders/42 \
-H 'Content-Type: application/merge-patch+json' \
-d '{ "status": "shipped" }'
# -> 200 OK
# --- DELETE: remove the resource (idempotent) --------------------------------
curl -X DELETE https://api.example.com/v1/orders/42
# -> 204 No Content on first call
# -> 204 No Content (or 404) on subsequent calls — server choice; still idempotent
# --- HEAD: metadata only, no body (used for cache checks, existence checks) ---
curl -I https://api.example.com/v1/orders/42
# -> 200 OK
# Content-Length: 1823
# ETag: "v3"
# --- OPTIONS: capabilities / CORS preflight ----------------------------------
curl -i -X OPTIONS https://api.example.com/v1/orders \
-H 'Origin: https://app.example.com' \
-H 'Access-Control-Request-Method: POST'
# -> 204 No Content
# Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE
# Access-Control-Allow-Headers: Content-Type, Authorization, Idempotency-Key
# Quick properties table:
# Method Safe Idempotent Cacheable Typical status
# GET yes yes yes 200 / 304
# HEAD yes yes yes 200
# POST no no* rare 201 (with Location)
# PUT no yes no 200 / 204
# PATCH no no** no 200 / 204
# DELETE no yes no 204 / 200 / 202
# * POST becomes idempotent-like when paired with Idempotency-Key and server dedup.
# ** PATCH is idempotent for whole-field set ops; not for append/array-push ops.
Common Mistakes & Pitfalls
Using POST for everything — losing idempotency guarantees, caching, and clear API semantics.
Check your understanding
Answer these without looking back at the article.
- What are the trade-offs when applying HTTP Methods Deep Dive — GET, POST, PUT, DELETE, PATCH Seman in production?
- What are the trade-offs when applying HTTP Methods Deep Dive — GET, POST, PUT, DELETE, PATCH Seman in production?
- What are the trade-offs when applying HTTP Methods Deep Dive — GET, POST, PUT, DELETE, PATCH Seman in production?
Related interview prep categories
1Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.