Identifying a replayed response

[jacob-buckaroo]

From both the client and server's perspective it would be beneficial to be able to identify a "replayed response". An example of this can be found when looking at Stipe's implementation. See https://docs.stripe.com/error-low-level#sending-idempotency-keys. Stripe adds a Idempotent-Replayed: true header to the response when a response from a previous request is returned.

Has this been considered?

[richsalz]

I don't believe it has come up in any of the discussions.

[jmileham]

This makes sense to me in particular if this spec ends up supporting an intermediary service (as Stripe's implementation is, and as this spec was initially inspired), because it'd add an explicit awareness for the client that, e.g. a 503 error response was terminal and would not resolve on further retry, without the client having to have that awareness statically based on the spec.

Other stuff maybe worth considering in this space:

OASIS Repeatability spec, as a comparison point, (that spec not supporting an intermediary service) has only one response header that only reveals that the request was accepted (meaning, applied once), but does not reveal whether this is the first or subsequent response. The OASIS response header also doesn't reveal whether the response is fresh (a representation the latest state of the resulting resource of an operation) or cached (the representation returned on first application). Maybe that's also interesting for a client to know in a generalized spec for the open internet, which I believe is a goal for this spec.

[jacob-buckaroo]

I've read up on the previous discussions related to intermediary service support and alternatives like OASIS Repeatability in the last couple of days. Very interesting stuff.

I would prefer that this spec would support idempotency as an intermediary service. Primarily because I like the idea of a straight forward idempotency layer that handles client / transient errors. Where both the client and the server know what te expect without too much complexity and exceptions.

Also I forsee easier widespread adoption of the spec when a few good libraries for both client and server exist that will "just work" out-of-the-box with minimal configuration. I don't really see any mandatory requirements in the spec that cannot be implemented in an intermediary service. Only a few optional features like:

• Idempotency Fingerprint: Field value match for each field in the request payload.
• Idempotency Fingerprint: Field value match for selected element(s) in the request payload.
• Idempotency Fingerprint: Request digest/signature.
• Unique composite key: Mentioned in the Security Considerations. Very broadly interpretable.

I personally think the Unique composite key should be a clearly defined mandatory requirement in this spec since it's needed to ensure a secure way of only ever returning replayed responses to the original requestor. This could be based on the value of the Authorization header for example.

I realize that I'm touching alot of other topics that overlap other discussions already in progress. My apologies for this, but I did this either way to see if there's any interest of the core contributors of this spec to discuss this further. And if so, how to proceed?

[darrelmiller]

It is my understanding that the original authors @sdatgit @jayadeba did not have the intention of providing a specification that enables building a generic intermediary service for implementing idempotency. How the server achieves idempotency is out of scope. This effort is focused on providing API consumers a interoperable experience.

[Without chair hat] As servers will need to track idempotency keys to guarantee idempotency, putting the burden on a client or retry connector code to manage state the necessary to generate an Idempotent-Replayed headers seems burdensome, especially considering the server can't actually trust the value provided.