What value does Idempotency Fingerprint add?

[darrelmiller]

The document suggests this can be optionally be implemented by the resource. What is the value that it adds to the interaction? What would be the consequences of two requests with the same idempotency-key but different fingerprints? Or different idempotency-keys and the same fingerprints?

[jmileham]

Unsolicited thoughts on fingerprinting: My team is doing an implementation of an idempotency system targeting rich clients (mobile apps and web SPAs, which can maintain their own idempotency protocol client implementations) and while compliance with a particular spec isn't our primary motivator, we implemented idempotency fingerprints for our use case (and were pleased to see them referenced in this document) so that we could provide a better experience for customers with fewer successful network round trips.

Scenario:

1. User submits a mutative request, receives a network timeout. [whether the request was a success is unknown to the client at this time]
2. User changes their mind, amends the request and resubmits. The protocol client retains the idempotency key for the resubmission intentionally.
3. Depending on whether the request was a success: a. If the initial request reached the server and was successful, the server reports that the attempted action is in conflict because of input mismatch, enabling the protocol client to report to the user that their request cannot be processed due to a conflict. b. If the initial request did not reach the server, the server performs the amended operation, and the client carries on without additional user interaction, or a need for additional automated reconciliation network attempts before the customer is allowed to resubmit.

Our hypothesis is that idempotency fingerprints are most useful for human-in-the-loop interactions with moderate to high risk of network partition. Most server-to-server idempotency scenarios can rely on the client not to change its mind about the operation wanting to be performed - the request payload is probably baked into a background job already alongside the idempotency key. For server-to-server idempotency protocols, we do not implement request fingerprinting for simplicity and to avoid many of the security risks I described in issue #40 just now.

[awwright]

I get the impression this section is just describing a best practice and providing implementation guidance. I'm not opposed to implementation guidance in specifications, but I don't see how this is useful. At the very least I suggest the normative language ought to be removed (the "MAY" doesn't make any guarantees that any party would find useful, it just seems to be descriptive), and the section moved to an appendix.