Live data from Hacker News

APIs, robustness, and idempotency

stripe.com

51–52 of 52 posts

Re: APIs, robustness, and idempotency

#51
post #43

Earlier quoted context omitted.

My team and I would love a blog post from you guys about the architecture of your idempotency tokens!

Our implementation is probably less sophisticated than you're thinking, but thanks! I'll pitch the idea to the team. To put it very simply, it's a middleware that stores a known response by an idempotency key's value and does a lookup on it on subsequent requests.

And so they did:

https://stripe.com/blog/idempotency

Re: APIs, robustness, and idempotency

#52
post #37
post #35

Earlier quoted context omitted.

Hi. Thanks for the very interesting article. Quick question regarding the following: > "On a response failure (i.e. the operation executed successfully, but the client couldn’t get the result), the server simply replies with a cached result of the successful operation." Have you considered having the server respond with different http-status-codes for the initial successful request as opposed to any nop-retries? This…

How would the client act differently upon it? Sounds about as useful as telling the client how many TCP packets in the connection had to be retransmitted by the server.

To give one extreme example: it's possible that the duplicate requests are occurring due to a client-side bug. If the duplicated request produces a different status code, a diligent/paranoid client can use this as a warning-signal that there might be a bug in the client's implementation.
Post reply on HN