3 ms·
I find that the easiest way to reason about idempotency is thinking about what happens when a client incorrectly retries a request (that is, resubmits it even t
by not_kurt_godel 8y ago
I find that the easiest way to reason about idempotency is thinking about what happens when a client incorrectly retries a request (that is, resubmits it even though it was successful the first time). You should always strive to make sure that the duplicate request is handled gracefully and without negative consequences as much as possible. Requests that mutate state should, as a general rule, accept the desired state as an explicit parameter - avoid toggles, increments, decrements, 'go to next step' types of calls. Idempotency tokens are another valid strategy, though they can be clunky to implement.
- drawkbox 8y agoThere was a story about toggles in apis on HN a few months ago [1][2], basically the toggle function was called for the garage door, which is clearly not idempotent, rather than an action like open/close so that is wasn't repeated. The toggle action led to opening and closing of the door repeatedly. Non idempotent requests are especially bad when tied to real physical machinery. [1] https://twitter.com/rombulow/status/990684453734203392 https://twitter.com/rombulow/status/990684453734203392 [2] https://news.ycombinator.com/item?id=16964907 https://news.ycombinator.com/item?id=16964907