I found this interesting article while perusing HackerNews the other day:
Designing robust and predictable APIs with idempotency
If I could summarize the most interesting points, they are:
- APIs connect distributed systems, and despite huge increases in network availability and reliability, networks still fail.
- As a result, sometimes a client can send an API request to a server and, if it does not receive a response, the client cannot know whether the request was handled properly.
- For a GET operation, it's no problem. The client can just send it again.
- For a POST or PUT, it's a problem. Resending a "debit" request might cause two debits!
- To address this situation, clients can contrive an transaction id, basically a unique identifier for the transaction. The article calls it an idempotency key.
- If the client fails to receive a response, it can re-send the same transaction with the same transaction id.
- It's incumbent upon the server implementation to store and track the transaction id and "do the right thing" when duplicate requests have been received
I recommend the article, it's a quick read.
Anyone out there in Apigee-land using transaction ids in this way? To suppose reliability in the face of potential failures in the distributed system?
I'd like to hear about it.
LinkedIn
Twitter