Idempotent HTTP Methods
Which HTTP methods are idempotent, and why does that matter for retries?
Answers use simple, clear English.
Quick interview answer
GET, HEAD, PUT, DELETE, OPTIONS, TRACE are idempotent — repeating the same request yields the same server state. POST is not. Safe retries on idempotent methods avoid duplicate side effects; POST needs idempotency keys for safe retry.
Detailed answer
GET, HEAD, PUT, DELETE, OPTIONS, TRACE are idempotent — repeating the same request yields the same server state. POST is not. Safe retries on idempotent methods avoid duplicate side effects; POST needs idempotency keys for safe retry. Idempotent ≠ safe. DELETE is idempotent but not safe.
Full explanation
Idempotent ≠ safe. DELETE is idempotent but not safe.
Real example & use case
Payment API retries a PUT /charges/{id} safely after a timeout, but POST /charges needs an Idempotency-Key header.
Pros & cons
Pros: clearer retry semantics. Cons: teams misuse POST for updates and then fear retries.