26 Request deduplication
This chapter covers...
- How to use request identifiers to prevent duplicate requests in a world of imperfect networks
- How to manage collisions with request identifiers to avoid confusing results
- Balancing caching and consistency of requests and responses
In a world where we cannot guarantee that all requests and responses will complete their journeys as intended, we'll inevitably need to retry requests as failures occur. This is not an issue for API methods that are idempotent, however for those that are now, we'll need a way to safely retry requests without causing duplicated work This pattern presents a mechanism to safely retry requests in the face of failure in a web API, regardless of the idempotence of the method.
26.1 Motivation
Unfortunately, we live in a very uncertain world and this is especially so in anything involving a remote network. Given the sheer complexity of modern networks and the variety of transmission systems available today, it's a bit of a miracle that we're able to reliably transfer messages at all! Sadly, this issue of reliability is just as prevalent in web APIs. Further, as APIs are used more frequently over wireless networks on smaller and smaller devices, sending requests and receiving responses over longer and longer distances means that we actually have to care about reliability more than we would on, say, a small, wired, local network.