Junior Level

HTTP methods are commands that tell the server what to do with a resource.

Main methods:

Method	Action	Example	Description
GET	Read	GET /users/1	Retrieve data (doesn’t change anything)
POST	Create	POST /users	Create a new resource
PUT	Full update	PUT /users/1	Replace the resource entirely
PATCH	Partial update	PATCH /users/1	Update part of the resource
DELETE	Delete	DELETE /users/1	Delete a resource

Method properties:

Method	Safe	Idempotent
GET	Yes	Yes
POST	No	No
PUT	No	Yes
PATCH	No	Depends on implementation
DELETE	No	Yes

• Safe: The method does not modify server state
• Idempotent: Repeated call with the same parameters yields the same result

Additional methods:

• HEAD: Like GET, but without response body (for existence check)
• OPTIONS: Discover which methods are supported for a resource (used in CORS)

---

Middle Level

POST: The Universal Tool

POST is the only method that is not idempotent. It is used:

• For creating resources
• For triggering processes (/jobs/1/start)
• For complex searches with large request bodies

Pitfall: Browsers show a “Confirm form resubmission” warning when pressing “Back” after a POST.

PUT vs PATCH

• PUT requires sending the entire state. If you omit a field — the server should null it out
• PATCH saves bandwidth (noticeable on large objects with 50+ fields), but is harder to implement. The server must distinguish: a field absent from the request (don’t touch) vs explicitly sent as null (set to null).

HEAD and OPTIONS: The Unsung Heroes

• HEAD: Returns headers without body. Used for checking ETag, Content-Length
• OPTIONS: Used in CORS. The browser makes a “Preflight request” before cross-domain requests

TRACE and CONNECT

• TRACE: Returns the client’s request back. Vulnerable to Cross-Site Tracing (XST) attacks. Always disable TRACE in production. In an isolated dev environment it may be useful for proxy debugging.
• CONNECT: For creating tunnels (through proxies for HTTPS). Not used in typical REST APIs.

Diagnostics

• 405 Method Not Allowed: Check the Allow header — the server must return a list of allowed methods
• Spring Security: CSRF protection is enabled for all methods except GET, HEAD, OPTIONS, TRACE

---

Senior Level

Properties Matrix (RFC 9110, 2022 — replaced RFC 7231)

Method	CRUD	Safe	Idempotent	Cacheable
GET	Read	✅	✅	✅
POST	Create/Action	❌	❌	⚠️*
PUT	Replace	❌	✅	❌
PATCH	Partial Update	❌	⚠️**	❌
DELETE	Delete	❌	✅	❌

*POST can be cacheable if appropriate headers are set (rare). *PATCH is idempotent if the update logic is deterministic (e.g., JSON Merge Patch).*

DELETE Idempotency Problem

If DELETE /users/1 returns 200, and the second call returns 404 — it’s still idempotent. Idempotency is about server state, not the response code.

Method Tunneling

Some older proxies don’t support PATCH. Solution: POST /resource with header X-HTTP-Method-Override: PATCH.

Pre-fetching and GET Safety

Browsers may pre-fetch GET methods. If GET is not “Safe” (e.g., GET /logout), this will cause accidental user logout.

Highload

• Idempotency affects the ability to automatically retry requests
• POST cannot be automatically retried on timeout (risk of double payments)
• Service Mesh (Istio, Linkerd) automatically retries idempotent requests on 503

---

Interview Cheat Sheet

Must know:

• 5 main methods: GET (read), POST (create), PUT (full update), PATCH (partial update), DELETE (delete)
• GET — safe and idempotent, must not change server state
• POST — the only method that is not idempotent
• PUT is always idempotent (full resource replacement), DELETE is also idempotent
• PATCH is idempotent only if the operation is deterministic (replace — yes, add — no)
• HEAD returns headers without body (for checking ETag, Content-Length)
• OPTIONS is used in CORS preflight requests
• TRACE and CONNECT are not used in typical REST APIs; TRACE is vulnerable to XST attacks

Frequent follow-up questions:

• Why is POST not idempotent? — Each POST can create a new resource (5 POSTs = 5 orders)
• Can GET be used for deletion? — No, GET must be safe; browsers may pre-load GET requests
• When to use PATCH instead of PUT? — For large objects or when multiple clients modify different fields in parallel
• What does OPTIONS return? — List of allowed methods for the resource (Allow header)

Red flags (DO NOT say):

• “POST can be safely retried on timeout” — this risks double operations
• “GET can change data, that’s fine” — GET must be Safe per RFC
• “PATCH is always idempotent” — depends on implementation (add to array — not idempotent)
• “TRACE is useful in production” — TRACE is vulnerable to Cross-Site Tracing attacks

Related topics:

• [[What is idempotency]]
• [[Which HTTP methods are idempotent]]
• [[Why GET and DELETE are idempotent]]
• [[Is POST idempotent]]
• [[What is the difference between PUT and PATCH]]