state machine/brittle long running process/fear of manual retry->idempotent request/response
Always, always, always work towards the rightmost side if you want the least side effects and highest reliability (critical for a distributed system built on unreliable parts!)
I'd like to say that declarative idempotency was an immediately obvious thing to the architects of the www, but what really happened is more like Darwinian evolution where each solution's fitness was measured by reliability. Declarative idempotency was also cheaper because requests/responses could be cached and scaled.
If we flip it around for a moment, imagine a web without these things. Every site would have a complex tangle of brittle code to do even the most trivial operations, and it wouldn't be able to pass data on to other sites (it would be an app). Without idempotency, users would have to be really careful to only click the send button once when they were transferring money (thankfully this hasn't happened much).
The one thing that I wish the web had though was a layer to make unreliable communication reliable. It would look something like a promise or future with no exceptional logic. That way we could think in terms of wiring up the inputs and outputs of many websites and then "load" it to execute the logic. Kind of like Ansible, where internally the logic is imperative but on the surface is declarative.
I'd also like to see declarative idempotence replace imperative code (especially object-oriented programming) at the developer level.
http://latentflip.com/imperative-vs-declarative
https://stackoverflow.com/questions/45016234/what-is-idempot...
https://en.wikipedia.org/wiki/Side_effect_(computer_science)
The early goal of the web was to create a longterm available, reliable, discoverable network of media over an inherently unreliable transport.
I keep trying to write a concise explanation of these but I can't fit it in a comment. Let's do it DECLARATIVELY haha:
imperative->functional->declarative
for()->foreach()->map()->executables+pipes->spreadsheet
C/BBS->perl/cgi-bin->Apache->HTML/CSS
manual network config->DNS
state machine/brittle long running process/fear of manual retry->idempotent request/response
Always, always, always work towards the rightmost side if you want the least side effects and highest reliability (critical for a distributed system built on unreliable parts!)
I'd like to say that declarative idempotency was an immediately obvious thing to the architects of the www, but what really happened is more like Darwinian evolution where each solution's fitness was measured by reliability. Declarative idempotency was also cheaper because requests/responses could be cached and scaled.
If we flip it around for a moment, imagine a web without these things. Every site would have a complex tangle of brittle code to do even the most trivial operations, and it wouldn't be able to pass data on to other sites (it would be an app). Without idempotency, users would have to be really careful to only click the send button once when they were transferring money (thankfully this hasn't happened much).
The one thing that I wish the web had though was a layer to make unreliable communication reliable. It would look something like a promise or future with no exceptional logic. That way we could think in terms of wiring up the inputs and outputs of many websites and then "load" it to execute the logic. Kind of like Ansible, where internally the logic is imperative but on the surface is declarative.
I'd also like to see declarative idempotence replace imperative code (especially object-oriented programming) at the developer level.