IntermediatePhone
2 min
HTTP Idempotent Methods
HTTPAPIsWeb
Advertisement
Interview Question
Which HTTP methods are idempotent and why does idempotency matter in API design?
Key Points to Cover
- Idempotent: GET, PUT, DELETE, HEAD, OPTIONS, TRACE (not POST)
- Multiple identical requests have the same effect
- Important for retries, caching, and safe error handling
Evaluation Rubric
Lists idempotent methods correctly40% weight
Defines idempotency accurately30% weight
Explains why it matters (retries/caching)30% weight
Hints
- 💡Be precise about POST vs PUT semantics.
Common Pitfalls to Avoid
- ⚠️Confusing Idempotency with Safety: Not understanding that idempotent methods like DELETE are not 'safe' (they do change server state) but are still idempotent.
- ⚠️Misimplementing PUT: Designing PUT to create new resources on repeated calls instead of strictly updating an existing resource or creating it to a specific, client-determined ID.
- ⚠️Failing to handle Idempotency Keys for POST: For critical operations where POST is used (e.g., payment), not providing an explicit mechanism (like an `Idempotency-Key` header) to make the operation idempotent when necessary.
- ⚠️Overlooking Edge Cases for Idempotent Methods: Forgetting that an idempotent operation's *response* might change (e.g., 200 OK vs. 404 Not Found for a GET on a deleted resource), but its *effect on server state* remains consistent.
- ⚠️Lack of documentation: Not clearly documenting which API endpoints are idempotent, leaving clients to guess and potentially make unsafe retry decisions.
Potential Follow-up Questions
- ❓Is PATCH idempotent?
- ❓How do idempotency keys help POST?
Advertisement