Explain common HTTP methods and which are idempotent
Reported in Snap USA engineering loops. Web fundamentals question essential for API and backend interviews.
Interview scenario
Often asked in Snap on-site or virtual loops at US offices (Bay Area, Seattle, NYC, Austin, and remote US). Prepare a clear spoken answer plus key trade-offs.
Model answer
Try answering aloud first
Cover trade-offs, structure, and a concrete example before revealing the baseline response.
How to frame this at Snap: Connect your answer to measurable impact, clarity of thought, and trade-offs the team cares about. Below is a strong baseline response you can adapt with your own project examples.
GET retrieves resources—safe (no body side effects) and idempotent. POST creates or triggers actions—neither safe nor idempotent (duplicate POST may create two orders).
PUT replaces resource at URL—idempotent (same PUT twice = same state). PATCH partial update—idempotency depends on patch semantics. DELETE idempotent—deleting twice still gone.
Idempotency matters for retries: clients replaying failed requests must not double-charge. Use idempotency keys on POST for payments; prefer PUT with client-generated IDs for upserts.
Status codes tie in: 201 Created with Location header on POST; 204 No Content on DELETE; 405 Method Not Allowed when route exists but verb does not.
Discussion
Comments (0)
Share how this question came up in your loop, or add tips for others preparing.
Log in to comment on this question.