4 ms·
The reason people like idempotency is because it is great for "at least once" systems (as opposed to "exactly once", which is hard to guarantee). But REST's ve
by fyp 7y ago
The reason people like idempotency is because it is great for "at least once" systems (as opposed to "exactly once", which is hard to guarantee).
But REST's version of idempotency isn't good for this. If you retry your request multiple times (due to flaky connection or whatever), it only guarantees the same server state if your duplicate requests are bunched up.
For example if you do a DELETE then create it again with a POST, if there is a duplicate straggler DELETE floating around it will end up redeleting your new recreation.
- thexa4 7y agoYou can make it idempotent again by requiring API users to use an If-Match header with the ETag of the state they're currently expecting. Also allows you to implement optimistic concurrency. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If...
- fyp 7y agoI said this in another comment and got downvoted too. Can the downvoters explain what they are downvoting for? What's wrong with if-match?
- SahAssar 7y agoThats why you only should allow delete, patch and put with a UUID or similar ID. Exactly the same could be said for a DB query not running in a transaction.
- _hl_ 7y agoThat's because DELETE is only idempotent, not commutative. Commutativity is solved by conflict-free replicated data types, but they can be extremely hard to implement without redefining correctness.