4 ms·

Maybe because the client should define what is the payload he wants to treat as idempotent. A request with the same message might have the same payload hash but

Maybe because the client should define what is the payload he wants to treat as idempotent. A request with the same message might have the same payload hash but it is sent on purpose twice.

jmull 5y ago
That’s not it… 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). Not to mention, it makes little sense for a server to be able to implement idempotency without understanding the idempotency semantics of the payloads it accepts.
- 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 ago
    Sure, 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.

Maybe because the client should define what is the payload he wants to treat as idempotent. A request with the same message might have the same payload hash but it is sent on purpose twice.

jmull 5y ago

That’s not it… 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). Not to mention, it makes little sense for a server to be able to implement idempotency without understanding the idempotency semantics of the payloads it accepts.

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 ago
  Sure, 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.