Did the Payment Go Through? Send It Again and Find Out Safely

An operation has this property when performing it repeatedly leaves the system in the same state as performing it once. Setting a value to seven qualifies, since setting it to seven again changes nothing. Adding seven to a value does not, since each repetition moves it further. Deleting a specific record qualifies, because the second attempt finds nothing to delete and the end state matches. The property is about the resulting state rather than about the response, so a repeat may legitimately report that there was nothing to do.

The fundamental problem is that a lost reply is indistinguishable from a lost request:

• •A client sends a request and receives no answer
• •The request may never have arrived
• •Or it may have been processed and the reply lost on the way back
• •The client cannot tell which from where it is standing
• •If the operation is safe to repeat, it simply retries
• •If it is not, retrying may charge a customer twice

Many genuinely useful operations are not naturally repeatable, and the standard fix is to make the server recognise a repeat. The client generates a unique key for the intended action and sends it with every attempt. The server records the key along with the result the first time, and on seeing the same key again returns the stored result without performing the work a second time. Payment systems work exactly this way, which is why an interface asking you to confirm a transfer usually creates such a key before the confirmation, not after it.

The standard vocabulary of the web assigns the property to particular request types by convention, and knowing which is which prevents a great deal of trouble. Fetching a resource changes nothing and is safe to repeat indefinitely, which is why browsers and caches retry it without asking. Replacing a resource wholesale with a supplied version qualifies, since sending the same version twice ends the same way. Removing a resource qualifies. Creating a new resource with a server-assigned identifier does not, because each attempt creates another, which is exactly the operation that needs a client-supplied key.

Several traps catch people who assume an operation is safe when it is not. An operation may be repeatable in its main effect and not in its side effects, so setting a record again is harmless while the email it triggers is sent twice. Stored keys must expire eventually or the store grows without limit, and a retry arriving after expiry is treated as new. Two different requests carrying the same key by accident cause serious confusion. And an operation that is safe on its own may not be when interleaved with a competing one, which is a separate problem requiring separate machinery.

An operation whose repetition leaves the same state can be retried freely, which matters because a client cannot distinguish a lost request from a lost reply. Operations that lack the property are given it by sending a unique key that the server records with its result and recognises on repeats. Side effects, key expiry and competing requests are where the assumption breaks.