What is idempotency and which HTTP methods are idempotent?
Assesses fundamental understanding of REST API Design conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
An operation is idempotent when performing it multiple times produces the same server state as performing it once.
- GET, HEAD, PUT and DELETE are idempotent by HTTP semantics.
- POST is not idempotent; repeated calls may create multiple resources.
- PATCH is not guaranteed to be idempotent.
PUT /users/42/email
Idempotency matters for retries: a client or gateway can safely retry an idempotent request after a timeout. For non-idempotent operations such as payments, use an idempotency key so the server can detect and deduplicate retries. Note that idempotency refers to server side effects, not the response code: the same DELETE may return 204 the first time and 404 the second, yet the end state is unchanged.
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.