4 ms·
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
by 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)
- jrochkind1 5y agoWhat I meant is, I can imagine a client tool where, when an idemptotency-key is given by the caller of the tool, the tool can treat the request as idempotent. Triggered by the presence of a supplied idempotency-key. The caller still needs to correctly supply (or not) the idempotency key, and supply a correct idempotency key, along with all other attributes of the request: http method, url, other headers, body. all of this needs to be constructed according to the documented behavior of the server, true. But just like if the caller says "make a GET request" the client tool knows it can be treated idempotently (automatically retried on ack failure for instance), if the caller says "make a POST with an idempotency-key", same. If the caller says "make a POST with request-id" where that is intentionally defined with no guarantee of idempotency, then not necessarily, I think?