3 ms·

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 confirm

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)
- jrochkind1 5y ago
  What 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?

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 ago
What 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?