A retry should not create a second order
A lost response should not turn one customer request into two transactions.
The idea in plain language
A request can succeed even when its response never reaches the caller. Malcolm Featonby explains how API design can make retries safer, so a temporary connection problem does not create another resource.
- Give each intended operation a caller-supplied identifier.
- Reuse that identifier when retrying the same intention.
- Define what happens with late requests and reused identifiers whose parameters have changed.
What it could look like at work
Imagine an employee ordering a laptop. The confirmation times out, so they try again. A service that recognizes the original request can avoid creating a second order. That recognition needs to be coordinated with the actual change; storing a key on its own is not enough.
Go a little deeper
The introduction provides the context. The sections on late arrivals and changed intent are useful when you are ready for implementation details.
Original article: Making retries safe with idempotent APIs.