4 ms·
Your parent is correct. Think of a simplified example of posting a $1 charge to a customer. POST /v1/charges `{amount: 100, currency: usd, customer: 123}`
by brandur 5y ago
Your parent is correct. Think of a simplified example of posting a $1 charge to a customer.
POST /v1/charges `{amount: 100, currency: usd, customer: 123}`
You might do that, and then later charge them another $1:
POST /v1/charges `{amount: 100, currency: usd, customer: 123}`
The request payload would be identical, so the API can't use just that to distinguish requests. Adding an `Idempotency-Key` lets you tell the server that these are purposely two independent charges.
> this RFC requires that the server know how to distinguish two requests with different payloads but the same idempotency-key value (and return a 422 response in that case).
This is an error checking facility to make sure that the idempotency keys are being used correctly. Sending a different request with the same idempotency key is non-sensical, so the server tells its client about the problem.
- jmull 5y agoSure, but there’s no reason or value in a standard “idempotency-key”. The API would simply have a requestId, or depositId or whatever, and place it in the header or body or whatever makes sense to the API. > This is an error checking facility to make sure that the idempotency keys are being used correctly. How circular. Idempotency keys are useful to make sure we’re using idempotency keys correctly.