Concept questionMedium~7 minHTTP API Semantics / 1 of 11

Interview question

What do safe and idempotent mean for HTTP methods, and why do those properties matter when clients retry requests?

Safe and idempotent HTTP method semantics

Explains HTTP safety and idempotency, then connects those guarantees to retries, side effects, and API design.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

A safe method is intended for retrieval and should not request a business-state change; GET, HEAD, and OPTIONS are common examples. An idempotent method can be repeated with the same intended effect as one request. PUT and DELETE are idempotent by definition, even though they are not safe, while POST is not generally idempotent. Idempotent does not mean every response is identical: a second DELETE can return 404 after the first one removed the resource.

Full answer below

Practice focus

GET, HEAD, OPTIONS, PUT, DELETE, POST, safe methods, idempotent effects, retries, and application side effects.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Retry behavior depends on what a method promises, not only on its name. Confusing safety with idempotency can turn ordinary network recovery into duplicate writes or hidden state changes.
A safe method is intended for retrieval and should not request a business-state change; GET, HEAD, and OPTIONS are common examples. An idempotent method can be repeated with the same intended effect as one request. PUT and DELETE are idempotent by definition, even though they are not safe, while POST is not generally idempotent. Idempotent does not mean every response is identical: a second DELETE can return 404 after the first one removed the resource.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I design handlers so the method semantics remain true at the application boundary. A GET may still produce logs or metrics, but it must not charge a card or advance an order. A repeated PUT with the same representation should converge on the same resource state. DELETE should tolerate the resource already being absent according to the contract. For operations that naturally use POST, an idempotency key can give a client a safe retry path without pretending that all POST requests are inherently idempotent.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I carry the guarantee through every side effect. An endpoint is not meaningfully idempotent if the database update converges but each retry sends another email or publishes another message. I store durable idempotency records or operation identifiers, define request-equivalence rules, and make concurrent duplicates resolve atomically. Retry policy also considers whether the client knows a request reached the server; a timeout leaves an ambiguous outcome. I monitor duplicate keys, replay results, and downstream duplication so the advertised method semantics survive failures rather than existing only in controller routing.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Calling every non-POST method safe.
Assuming idempotent means the status code never changes.
Using GET for an operation that changes business state.
Making the database write idempotent while duplicating messages or emails.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The retry policy is based only on status codes and ignores method semantics.
A GET endpoint performs a meaningful state transition.
Concurrent retries can both pass a duplicate check and execute the operation.
The API claims idempotency but has no durable definition of the repeated request.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why can two idempotent DELETE responses differ?
How would you make a payment-creation POST retryable?
Which side effects must participate in the idempotency design?

Continue the section

Next in HTTP API Semantics: Choose HTTP status codes

Step 2 of 11

Choose HTTP status codes for real API outcomes

Opening drill

Concept questionMedium~7 minHTTP API Semantics / 1 of 11

Interview question

What do safe and idempotent mean for HTTP methods, and why do those properties matter when clients retry requests?

Safe and idempotent HTTP method semantics

Explains HTTP safety and idempotency, then connects those guarantees to retries, side effects, and API design.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

GET, HEAD, OPTIONS, PUT, DELETE, POST, safe methods, idempotent effects, retries, and application side effects.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Retry behavior depends on what a method promises, not only on its name. Confusing safety with idempotency can turn ordinary network recovery into duplicate writes or hidden state changes.
A safe method is intended for retrieval and should not request a business-state change; GET, HEAD, and OPTIONS are common examples. An idempotent method can be repeated with the same intended effect as one request. PUT and DELETE are idempotent by definition, even though they are not safe, while POST is not generally idempotent. Idempotent does not mean every response is identical: a second DELETE can return 404 after the first one removed the resource.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I design handlers so the method semantics remain true at the application boundary. A GET may still produce logs or metrics, but it must not charge a card or advance an order. A repeated PUT with the same representation should converge on the same resource state. DELETE should tolerate the resource already being absent according to the contract. For operations that naturally use POST, an idempotency key can give a client a safe retry path without pretending that all POST requests are inherently idempotent.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I carry the guarantee through every side effect. An endpoint is not meaningfully idempotent if the database update converges but each retry sends another email or publishes another message. I store durable idempotency records or operation identifiers, define request-equivalence rules, and make concurrent duplicates resolve atomically. Retry policy also considers whether the client knows a request reached the server; a timeout leaves an ambiguous outcome. I monitor duplicate keys, replay results, and downstream duplication so the advertised method semantics survive failures rather than existing only in controller routing.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Calling every non-POST method safe.
Assuming idempotent means the status code never changes.
Using GET for an operation that changes business state.
Making the database write idempotent while duplicating messages or emails.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The retry policy is based only on status codes and ignores method semantics.
A GET endpoint performs a meaningful state transition.
Concurrent retries can both pass a duplicate check and execute the operation.
The API claims idempotency but has no durable definition of the repeated request.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why can two idempotent DELETE responses differ?
How would you make a payment-creation POST retryable?
Which side effects must participate in the idempotency design?

Continue the section

Next in HTTP API Semantics: Choose HTTP status codes

Step 2 of 11

Choose HTTP status codes for real API outcomes

What do safe and idempotent mean for HTTP methods, and why do those properties matter when clients retry requests?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

What do safe and idempotent mean for HTTP methods, and why do those properties matter when clients retry requests?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section