5 ms·

Why don't they generate the key from the payload if it has to be unique and request specific?

lanstin 5y ago
You might have two identical requests, say for two identical credit card purchases, or you might have faulty retry on the same request.
hit8run 5y ago
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.
vishnugupta 5y ago
Because only the caller knows if two payloads, despite being identical, are genuinely different requests or retries of the same request. That said, in this age of micro services and large-scale distributed systems a request may get retried by a framework layer down a call-chain regardless of whether the request originator intended it or not.

You might have two identical requests, say for two identical credit card purchases, or you might have faulty retry on the same request.

hit8run 5y ago

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.

vishnugupta 5y ago

Because only the caller knows if two payloads, despite being identical, are genuinely different requests or retries of the same request. That said, in this age of micro services and large-scale distributed systems a request may get retried by a framework layer down a call-chain regardless of whether the request originator intended it or not.