HTTP Methods Explained (GET, POST, PUT, PATCH, DELETE)
Understand HTTP methods — GET, POST, PUT, PATCH, DELETE — their safety and idempotency guarantees, with interview questions answered.
Expected Interview Answer
HTTP methods define the intended action on a resource: GET retrieves data safely without side effects, POST creates a resource or triggers processing, PUT replaces a resource entirely, PATCH partially updates it, and DELETE removes it — each with distinct safety and idempotency guarantees.
A method is “safe” if it does not change server state (GET, HEAD, OPTIONS); it is “idempotent” if repeating the same request produces the same server state as making it once (GET, PUT, DELETE are idempotent, POST generally is not, PATCH depends on implementation). PUT expects the full replacement representation of a resource and creates it at the given URI if absent, whereas PATCH sends a partial diff and only applies the specified changes. POST is the odd one out because it is neither safe nor idempotent by contract — calling it twice may create two resources, which is why clients often use idempotency keys for retries. Correctly choosing methods matters for HTTP caching (GET responses are cacheable by default; POST responses generally are not), for browser and proxy retry behavior (browsers freely retry idempotent methods but not POST), and for REST API design clarity between clients and servers.
- Communicates intent (read vs create vs replace vs modify vs remove) explicitly
- Safety and idempotency guarantees drive safe automatic retries and caching
- Enables proxies, browsers, and CDNs to make correct optimization decisions
- Forms the contract REST APIs rely on for predictable client behavior
AI Mentor Explanation
GET is like a spectator checking the live scoreboard — looking at it as many times as they want never changes the score. POST is like a new player registering for the tournament roster — submitting the form twice by accident creates two duplicate entries, which is not idempotent. PUT is like replacing the entire team sheet with a brand-new one for that match, while PATCH is like editing just one player's batting position on the existing sheet without touching the rest, and DELETE is like withdrawing a player's registration entirely.
Step-by-Step Explanation
Step 1
Choose intent
Decide whether the operation reads (GET), creates (POST), fully replaces (PUT), partially updates (PATCH), or removes (DELETE) a resource.
Step 2
Check safety
GET, HEAD, and OPTIONS are safe — they must not change server state, which lets browsers prefetch and caches store them.
Step 3
Check idempotency
GET, PUT, and DELETE are idempotent (repeating has the same effect as once); POST is not, so retries need care.
Step 4
Design the response
Return the appropriate status code (200/201/204) and body so the client can confirm the intended action actually happened.
What Interviewer Expects
- Correctly maps each method to its intended semantic action
- Distinguishes safe methods from unsafe ones
- Distinguishes idempotent methods (GET/PUT/DELETE) from non-idempotent POST
- Explains PUT (full replace) vs PATCH (partial update) precisely
Common Mistakes
- Using GET to modify data because “it is simpler”
- Treating PUT and PATCH as interchangeable
- Assuming POST is idempotent and safe to blindly retry
- Forgetting DELETE and PUT are idempotent even though they change state
Best Answer (HR Friendly)
“HTTP methods are like different verbs you attach to a web request to say what you want to do: GET means “just show me this,” POST means “create something new,” PUT means “replace this entirely,” PATCH means “update part of it,” and DELETE means “remove it.” Getting these right matters because browsers and servers behave differently based on the verb — for example, it is safe to retry a GET automatically, but retrying a POST could accidentally create duplicates.”
Code Example
# GET - read a resource
curl -s https://api.example.com/users/42
# POST - create a new resource
curl -s -X POST https://api.example.com/users \
-H "Content-Type: application/json" \
-d '{"name":"Ada Lovelace"}'
# PUT - fully replace a resource
curl -s -X PUT https://api.example.com/users/42 \
-H "Content-Type: application/json" \
-d '{"name":"Ada Lovelace","role":"engineer"}'
# PATCH - partially update a resource
curl -s -X PATCH https://api.example.com/users/42 \
-H "Content-Type: application/json" \
-d '{"role":"principal engineer"}'
# DELETE - remove a resource
curl -s -X DELETE https://api.example.com/users/42Follow-up Questions
- Why is POST neither safe nor idempotent, and how do idempotency keys help?
- What HTTP status codes typically pair with each method (201, 204, 200, 404)?
- How does HTTP caching treat GET responses differently from POST?
- When would you choose PATCH over PUT in a REST API design?
MCQ Practice
1. Which HTTP method is idempotent but not safe?
DELETE changes server state (not safe) but repeating it has the same end effect as calling it once (idempotent).
2. What is the key difference between PUT and PATCH?
PUT sends the complete replacement representation; PATCH sends only the fields that changed.
3. Why do browsers avoid automatically retrying a failed POST request?
Retrying POST can create duplicate resources or trigger the action twice, unlike idempotent methods.
Flash Cards
Is GET safe and idempotent? — Yes — GET is both safe (no state change) and idempotent.
Is POST idempotent? — No — repeating a POST can create duplicate resources or effects.
PUT vs PATCH? — PUT replaces the entire resource; PATCH applies a partial update.
Is DELETE idempotent? — Yes — deleting an already-deleted resource still results in it being gone.