technical · standard
"GET, POST, PUT, DELETE, and idempotency" the PM interview answer
Can you explain GET, POST, PUT, and DELETE, and what does idempotency mean?
This is a contract question, not a vocabulary quiz. The interviewer wants to know whether you understand HTTP methods as a set of behavioral guarantees between client and server, and whether you can connect idempotency to real product consequences: duplicate charges, ghost orders, broken retries, and agentic AI loops that run endpoints more than once.
Structure a strong answer
Open with the framing, walk each method in one crisp sentence tied to behavior, then anchor the pivot to idempotency in a concrete failure scenario.
strong
"HTTP methods are a contract between the client and the server about what will happen and whether it's safe to repeat. That 'safe to repeat' property is idempotency, and it's the part that matters most to product decisions.
GET is both safe and idempotent. Safe means it makes no server-side change at all. Idempotent means calling it 10 times leaves the server in the same state as calling it once. GET is always safe to retry automatically on failure.
POST is neither. Each call can create a new resource. If a mobile user taps Pay and the network drops, and the app auto-retries the POST, they may be charged twice. That's a product failure, not a backend bug. Stripe's answer is idempotency keys: the client generates a UUID, sends it as an Idempotency-Key header, and the server caches the result for 24 hours. On retry, the server returns the exact same response instead of running the charge again. The PM lesson: POST endpoints that trigger real-world side effects need idempotency keys, and that's a decision the PM should flag during design, not discover after a support ticket.
PUT is idempotent but not safe. It changes state, but calling it 10 times leaves the same result as calling it once because it's a full replacement: set this resource to exactly this value. It's safe to auto-retry on failure.
DELETE is idempotent. After the first call the resource is gone. Subsequent calls return a 404, but the server state doesn't change further. Safe to retry.
PATCH is the odd one. It's a partial update, and idempotency depends on the operation. 'Set field X to value Y' is idempotent. 'Append item to list' is not. That distinction matters when you're designing an API: partial updates that clients might retry on network failure should be written as set operations, not append operations, or they need idempotency keys.
In 2026, this is a live concern beyond payments. LLM agents call API endpoints in retry loops. If a tool call hits a non-idempotent POST, a single agent task can book the same flight three times or create three duplicate support tickets on every network hiccup. The question I'd ask for any endpoint exposed to an agent: is this safe to retry automatically, or does it need a key?"
weak
"GET retrieves data, POST sends data, PUT updates a resource, DELETE removes it. Idempotent means calling the method multiple times gives the same result." This tells the interviewer you memorized a list. It skips the behavioral contract, conflates safe and idempotent, doesn't explain why PATCH is different, and connects nothing to a product decision. At API-first companies like Stripe, Twilio, or Shopify, this answer signals surface-level prep.
The PM judgment
The interviewer is checking for two things. First: do you understand the difference between safe (no server-side change at all) and idempotent (same outcome on repeat, but may change state on the first call)? These are not the same thing, and candidates who conflate them are noticed. GET is both. PUT and DELETE are idempotent but not safe. POST is neither. PATCH is situational.
Second: can you connect this to a product decision without being prompted? The canonical product failure is the double charge on POST retry. The canonical product solution is the idempotency key. A PM who can walk from “the network dropped” to “the client retried” to “we need a key” to “keys expire after 24 hours on Stripe so long-running operations need a different strategy” is demonstrating the technical fluency that matters at platform companies.
Safe vs idempotent: the precise table
| Method | Safe | Idempotent | Notes |
|---|---|---|---|
| GET | Yes | Yes | Always retry-safe |
| HEAD | Yes | Yes | Same as GET, no body |
| OPTIONS | Yes | Yes | Preflight/discovery |
| PUT | No | Yes | Full replacement; retry-safe |
| DELETE | No | Yes | 404 after first call is fine |
| POST | No | No | Needs idempotency key for retries |
| PATCH | No | Situational | Set operations yes, append operations no |
The 2026 angle
Idempotency moved from a distributed systems concern to a product design constraint when LLM agents started calling tool APIs in retry loops. A non-idempotent POST in an agent workflow can generate duplicate resources on every retry, with no human in the loop to notice until the damage is done. The viable product question is: which of your endpoints are exposed to agents, and are they safe to retry? The lovable product question is: when a retry does fail, does the user see a clear error, or does your system silently create a mess they discover later?
This is the same problem Stripe solved for payments a decade ago, now playing out at the agent-tool layer across every product category. PMs who understand idempotency as a safety property, not a trivia fact, can make the right call during API design rather than after a production incident.
For more on building and evaluating API products, see what is an API and API versioning. The API PM role guide covers what hiring managers at platform companies are actually screening for across the full loop.