When should you use PUT, PATCH or POST?
Interviewer Expectations for this Question
01
Core Competency
Assesses fundamental understanding of REST API Design conventions, runtime behavior, and memory/performance considerations.
02
Evaluation Criteria
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Comprehensive Model Answer
Verified Solution
- POST creates a subordinate resource or triggers a non-idempotent action. The server assigns the identifier and returns 201 with a
Locationheader. - PUT replaces the entire resource at a known URI and is idempotent. Any omitted field is reset, which surprises clients doing partial updates.
- PATCH applies a partial modification and is generally not idempotent unless the patch document is written to be so.
PATCH /users/42
Content-Type: application/merge-patch+json
{ "email": "new@example.com" }
Two PATCH formats dominate: JSON Merge Patch (RFC 7396, simple) and JSON Patch (RFC 6902, a list of explicit operations). Prefer PUT when the client owns the full representation, PATCH when it does not. A frequent pitfall is using PUT with a partial body, which silently wipes unspecified fields.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.