Comparison
Idempotency keyvsIdempotent HTTP method
Idempotency key
the client sends a unique id with the payment request so that retrying it cannot charge the card twice.
A caller-supplied identifier that lets the server recognise a retry of a request it has already handled and return the original result. It is the standard way to make a non-idempotent operation safe to retry over an unreliable network. The server side needs storage with a retention window and a rule for what happens when the same key arrives with a different body.
Full entry →Idempotent HTTP method
you make the endpoint a PUT with a client-chosen id, so a nervous client can send it three times without creating three records.
The HTTP contract that GET, PUT and DELETE can be repeated without additional effect, while POST cannot. Clients, proxies and retry libraries rely on it, so a PUT with non-idempotent behaviour will be retried into a bug by infrastructure you do not control. If you need a non-idempotent create to be retry-safe, take an idempotency key.
Full entry →