FWIW, I enjoyed your engagement throughout the thread above, fighting the good fight.
I think there is also a risk of an "easy API" when it leads to magical thinking and sloppy development. If the naive client programmer starts to think the reliability is handled for them, they may also flub the handling of the idempotence key that remains the crux here. E.g. not persisting them well enough and returning to a situation where the user can accidentally make duplicate payments just like the naive system with no idempotence feature...
Not without some kind of delay function and probably filtering/evaluation of which new accounts get this capability...
Everyone here should be familiar with exponential growth of n-ary trees. If you can get one of these accounts and each new invitee gets to invite 2 more, you can already have accounts gone wild.
So, the scammer should send an invite to a real person from one percent of the accounts in the tree, wait a few months, then flip the evil bit on 90-95% of the accounts they registered. If the whole tree is cut off the reputational damage is really high (10,000 valid users nuked because of actions other accounts took...)
And it didn't even take attestation to cause this absurd situation where many businesses or social groups were only reachable behind Facebook or Whatsapp or whatever.
To me this is such a bizarre cyberpunk dystopia. Like if we could only send letters and packages to people subscribed to the same private postal service, or drive on roads that had cross-licensing with our brand of car.
When I was an expat, there was a subtle kind of experience in settling into buying groceries and getting haircuts from the local providers. Or shopping for furniture for our own apartment, or hiring someone to do remodeling on a house...
But, I'm the type who also finds enjoyment in the same scenic trails and camping areas visited hundreds of times in my life in different seasons, etc. I don't need to try to see everything once in a superficial, whirlwind of a tour...
Idempotence already requires some client thinking if you want to conform to HTTP specs.
I.e. idempotent DELETE with proper protocol behavior requires that one request see the 200 OK or 204 No Content and the other sees 404 Not Found, because the delete has already happened. It would be misleading to say 200 OK to both, because that answer means the resource was there when the request arrived.
Honestly, the whole HTTP resource model has a different conceptual backing for state management than the independently developed "idempotence" concepts in distributed systems. Those non-HTTP concepts came from more message-based rather than resource-based architectural assumptions.
The cleanest mapping in the spirit of HTTP would be that you do multiple round trips. A POST creates a new idempotence context, a bit like "start a transaction". The new URI is the key for coordinating state change and allowing restart/recovery.
As I remember it, the idea of idempotence keys in headers really came from the SOAP RPC mindset. It's kind of funny to see it persisting in some hybrid SOAP + REST mental model.
> The cleanest mapping in the spirit of HTTP would be that you do multiple round trips. A POST creates a new idempotence context, a bit like "start a transaction". The new URI is the key for coordinating state change and allowing restart/recovery.
I think that gave me "Enterprise Java Beans PTSD". I.e. an over-engineered solution that adds complexity for both the client and server in the name of some sort of "protocol purity".
People bolted on idempotent semantics onto HTTP because it wasn't provided natively by the protocol, so I don't think it makes sense to go through some hoop-jumping gymnastics for the sake of conforming to a spec that doesn't describe the necessary semantics in the first place.
FWIW, I'm not particularly fond of HTTP. But there is PTSD in both directions. Doing random things ignoring (or subverting) "protocol purity" often create disastrous effects when they haven't considered how the larger system will behave when you have various middleware bits that are essentially obeying different protocols while superficially claiming to use an interoperable standard.
When I let myself ruminate, it irks me that we all let HTTP become the defacto "internet protocol" just because of firewalls. Because there was a cargo cult idea that HTTP is benign and so one of few ports allowed almost everywhere, we do stupid contortions to squeeze every protocol through an HTTP tunnel.
These short-sighted acts of laziness accumulate into HTTP everywhere. And of course, the firewall is nearly pointless when "everything" is going through that one hole anyway.
Being charitable, I'd say the poster above is saying that in the web architecture you can (should?) shift more of the burden for idempotence to the client.
But, rather than 409, I'd say that you should be using opportunistic concurrency control if you adopt this perspective. There should be a resource context for the request, so the client can obtain an ETag and send If-None-Match headers, and get a 412 response if things are out of sync. That allows them to retry a failed/lost request and safely prevent a double action.
Under a 412, they have to step back and retry a larger loop where they GET some new state and prepare a new action. Just like in DB transaction programming, where your failed commit means you roll back, clean the slate, and start a whole new interrogation of transaction-protected state leading up to your new mutation request.
The client is already participating in a transaction in a distributed system. There is no way to change the reality of that. Suggestions about masking this only make the composite system unsound and will not improve net service reliability improvement.
That doesn't mean that idempotency keys have to be used. You can certainly hash message content if that is documented behavior. That probably only makes sense when there is already some logical session or transaction identifier that makes dedupe semantics clear.
The system you propose might be sound and might be necessary in some systems, but I can't think of what they might be that wouldn't be better served by the simpler solution that is already widely used for this purpose.
It's also a major concern to have a supply chain that can be protected from foreign manipulation.
A compromised supply chain is a huge intelligence/national security risk, not just for military platforms but everything from government and commercial datacenters to personal devices used by both public and private sector individuals.
This is more my imagining a book plot than any real insight, but...
This wouldn't be Apple's first rodeo with Intel. They know how prior partnerships soured. Could a sufficiently powerful shareholder, like the US government, help mitigate Apple's concerns about the outcome of a new partnership? I.e. that Intel would be pressured to honor certain strategic obligations, even if the leadership at Intel isn't so keen?
How can the USG improve the competitiveness of INTC's process nodes with political pressure?
Was the concern in the past that Intel wasn't honoring strategic obligations or was it that Apple realized their tech sucked and TSMC was the only viable path to deliver world-leading products?
I think there is also a risk of an "easy API" when it leads to magical thinking and sloppy development. If the naive client programmer starts to think the reliability is handled for them, they may also flub the handling of the idempotence key that remains the crux here. E.g. not persisting them well enough and returning to a situation where the user can accidentally make duplicate payments just like the naive system with no idempotence feature...
reply