4 ms·
Too much emphasis on interfaces than on programmability. I don't even know if they follow their own rules too. Also, they define DELETE as idempotent, which is
by vkaku 7y ago
Too much emphasis on interfaces than on programmability. I don't even know if they follow their own rules too.
Also, they define DELETE as idempotent, which is a little different from how some of us write APIs.
- zerocrates 7y agoHow are you thinking of doing it differently? DELETE is typically considered idempotent.
- treve 7y agoThey don't define DELETE as idemptotent, the HTTP standard does. It also feels very natural for DELETE to be IMHO, so I would be curious what strange thing you do
- alkonaut 7y agoNote that idempotent in this context means “2 calls will end up with the same server state as one call”. It does not mean for example that the second call can’t return a different response than the first.
- JMTQp8lwXL 7y agoIf "idempotent" means "do the same thing", one would expect the same response on a subsequent call, no? "Do the same thing" isn't specific enough. Does it mean the state of the system? Does it mean the response code? Does it mean the response body? Does it mean all of these things? All seem like reasonable interpretations.
- alkonaut 7y agoIn the context of REST it means the same server state (a database table state, a mailbox state, file system state etc) It doesn’t mean “do the same thing” or “get the same response”, only “end up in the same place”. You can do a delete x, get an OK response, and the important state is that x is now deleted on the server. Then the next call to delete x does nothing (which is different from the first which deleted x!). So to be idempotent it has to do something different. The response in the second case can be both “ok” (because the thing is deleted) but also e.g “x doesn’t exist”.
- fyp 7y agoThe 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.