4 ms·

It's more appropriate IMO to name it something like "Request-Identifier". All the client should indicate is that if you get 2 or more POSTs with that same Id, y

by vp8989 5y ago

It's more appropriate IMO to name it something like "Request-Identifier". All the client should indicate is that if you get 2 or more POSTs with that same Id, you are free to no-op on any after the 1st successfully handled one. Idempotency is an emergent property of a system so it doesn't make sense that a client would dictate the key that's used to provide that behavior. So if the Idempotency-Key is quite likely not to be the actual "Idempotency-Key" in any sufficiently complex system, then don't name it that.

joshribakoff 5y ago
Yes I have seen idempotency keys generated on the client that were comprised of the date and amount of money used to make a payment. Don’t do this. Just use a randomly generated request ID when the request hits the API. The idempotency key is (usually) there to prevent things like an RPC or event (in the backend) being retried causing duplicate side effects. Presumably you still want users to be able to intentionally submit two payments for the same amount on the same date (csrf tokens are more appropriate to prevent accidental duplicate submission)
karmakaze 5y ago
I want both. If there are two network requests for the same action, I want to be able to trace them distinctly and also know that they are doing one thing.
- mercantile 5y ago
  Exactly this. Multiple requests with the same idempotency key are still different requests, and you want to be able to track them independently. Also worth noting that a header named 'Request-Id' is already a widespread convention. You'll see one back from many popular APIs like AWS or Stripe, and definitely want a name for the idempotency header that differentiates itself from that.
  - vp8989 5y ago
    They are 2 distinct concepts for sure, but if you also need to track each request independently then it would seem more robust to generate a separate Id for that from within the scope of your system. I don't think you would want to rely on a client to differentiate "physical" requests for you. Maybe "Logical-Request-Identifier" and "Physical-Request-Identifier"?
    - karmakaze 5y ago
      On the surface this sounds about right, but how do we ensure that we only create one of these? Every layer will want to create a new id as not trusting the id given to it as 'new'. Having the actual client generate both is the simplest.
bhawks 5y ago
Providing 'idempotency' in this case commonly means to be robust against transient network partitions and timing delays. This goal can be met efficiently with a timebound nonce. (Indeed that is a common approach). A request identifier is a much stronger and user visible property to your API. Where an 'idempotency' key is used simply to prevent replays, a request identifier is a property that a backend needs to store, index and serve queries against for a much longer period of time. Furthermore this data must be client generated by definition which would require some namespacing mechanism to keep the data model logically correct. Alternatively, just give me a random number (as this rfc suggests).
jrochkind1 5y ago
It matters that the client knows the server is offering idempotency, because then the client can safely do things like re-try a request if it didn't get confirmation -- at least I think this makes that possible? It is suprising to me the standard doesn't mention it though, so maybe I'm missing the boat? If a client just knows it provided a "request-id", but not that the server provides idempotent semantics, the client can not safely re-try a request in which confirmation was not retrieved. Or, you know how when you click the back button and see that message "this was the result of a POST request, but we can't actualy show you the response" -- because the response wasn't cacheable/cached, and the client can't safely re-do the request to get a new response, because the request was not idempotent. The client knowning the request is idempotent avoids all sort of inconvenient (and sometimes confusing) client/user-agent behavior. For both ordinary human-readable HTML, and APIs (although by being an HTTP header, I guess this standard is only about API's as a use case?). Just knowing "we supplied a request-id we don't know what the server plans to do with it" is not sufficient. This is why HTTP distinguishes between methods that are idempotent and not -- which just means methods that it's, by the standard, the server's obligation to implement as idempotent. This is a way of making any method opt-in idempotent. I think?
- systoll 5y ago
  That’ll be a problem regardless – if the client provides an idempotency-key but the server doesn’t use it, it’ll reprocess on retry. Under this spec, the client needs to check server docs to figure out if/when/how idempotency keys are used. The weird part of calling them idempotency keys is that seperate requests will often fall in the same idempotent group. EG: If traffic lights were controlled over HTTP, a pedestrian pressing the crossing button 20 times in a row would create 20 distinct requests which would need 20 distinct idempotency keys. But pressing the button once is the same as pressing it 20 times.
  - nextaccountic 5y ago
    > Under this spec, the client needs to check server docs to figure out if/when/how idempotency keys are used. The client needs to check the docs for other aspects of the API as well (such as the right HTTP verb, other required headers, etc)

by vp8989 5y ago

joshribakoff 5y ago

Yes I have seen idempotency keys generated on the client that were comprised of the date and amount of money used to make a payment. Don’t do this. Just use a randomly generated request ID when the request hits the API. The idempotency key is (usually) there to prevent things like an RPC or event (in the backend) being retried causing duplicate side effects. Presumably you still want users to be able to intentionally submit two payments for the same amount on the same date (csrf tokens are more appropriate to prevent accidental duplicate submission)

karmakaze 5y ago

I want both. If there are two network requests for the same action, I want to be able to trace them distinctly and also know that they are doing one thing.

mercantile 5y ago
Exactly this. Multiple requests with the same idempotency key are still different requests, and you want to be able to track them independently. Also worth noting that a header named 'Request-Id' is already a widespread convention. You'll see one back from many popular APIs like AWS or Stripe, and definitely want a name for the idempotency header that differentiates itself from that.
- vp8989 5y ago
  They are 2 distinct concepts for sure, but if you also need to track each request independently then it would seem more robust to generate a separate Id for that from within the scope of your system. I don't think you would want to rely on a client to differentiate "physical" requests for you. Maybe "Logical-Request-Identifier" and "Physical-Request-Identifier"?
  - karmakaze 5y ago
    On the surface this sounds about right, but how do we ensure that we only create one of these? Every layer will want to create a new id as not trusting the id given to it as 'new'. Having the actual client generate both is the simplest.

bhawks 5y ago

Providing 'idempotency' in this case commonly means to be robust against transient network partitions and timing delays. This goal can be met efficiently with a timebound nonce. (Indeed that is a common approach). A request identifier is a much stronger and user visible property to your API. Where an 'idempotency' key is used simply to prevent replays, a request identifier is a property that a backend needs to store, index and serve queries against for a much longer period of time. Furthermore this data must be client generated by definition which would require some namespacing mechanism to keep the data model logically correct. Alternatively, just give me a random number (as this rfc suggests).

jrochkind1 5y ago

It matters that the client knows the server is offering idempotency, because then the client can safely do things like re-try a request if it didn't get confirmation -- at least I think this makes that possible? It is suprising to me the standard doesn't mention it though, so maybe I'm missing the boat? If a client just knows it provided a "request-id", but not that the server provides idempotent semantics, the client can not safely re-try a request in which confirmation was not retrieved. Or, you know how when you click the back button and see that message "this was the result of a POST request, but we can't actualy show you the response" -- because the response wasn't cacheable/cached, and the client can't safely re-do the request to get a new response, because the request was not idempotent. The client knowning the request is idempotent avoids all sort of inconvenient (and sometimes confusing) client/user-agent behavior. For both ordinary human-readable HTML, and APIs (although by being an HTTP header, I guess this standard is only about API's as a use case?). Just knowing "we supplied a request-id we don't know what the server plans to do with it" is not sufficient. This is why HTTP distinguishes between methods that are idempotent and not -- which just means methods that it's, by the standard, the server's obligation to implement as idempotent. This is a way of making any method opt-in idempotent. I think?

systoll 5y ago
That’ll be a problem regardless – if the client provides an idempotency-key but the server doesn’t use it, it’ll reprocess on retry. Under this spec, the client needs to check server docs to figure out if/when/how idempotency keys are used. The weird part of calling them idempotency keys is that seperate requests will often fall in the same idempotent group. EG: If traffic lights were controlled over HTTP, a pedestrian pressing the crossing button 20 times in a row would create 20 distinct requests which would need 20 distinct idempotency keys. But pressing the button once is the same as pressing it 20 times.
- nextaccountic 5y ago
  > Under this spec, the client needs to check server docs to figure out if/when/how idempotency keys are used. The client needs to check the docs for other aspects of the API as well (such as the right HTTP verb, other required headers, etc)