A REST API is really an app specific network protocol that happens to build on HTTP instead of TCP. It's not actually an API in the sense we're talking about above. Most obviously there's no standard way for a web server to say "I implement this standard typed interface X", and even if there was, there's no way to ask browsers to enumerate all the web apps the user "has" that implements interface X because browsers don't have any notion of a user "having" an app to begin with. That's sometimes beneficial, and sometimes it just means things can't integrate with each other.

In contrast stuff like DCOM/OLE supported tons of features that REST doesn't even try to address so it's an apples/oranges comparison to a large extent.

Don't get me wrong - decoupling the app APIs from the underlying operating systems has advantages, and I'm not trying to bring DCOM back, but clearly the advantages aren't that huge because on mobile a more modern take on the exact same concepts stomped web tech completely. Everyone wants native Android/iOS apps and they want them so badly that companies will write the same app frontend twice to satisfy that need.

"The distribution model of the web is precisely what is so amazing about it. It is already decentralized. It has zero distribution friction."

True, but this is engineering. There are always tradeoffs. It gets this zero distribution friction by simply ignoring any use cases that don't fit its document-oriented model. Most obviously, every approach to making the web support poor or non-existent connectivity is terrible and has never gained traction, but that's a problem. Many, many apps need to be able to run offline. Anything that manages a critical process of any kind simply cannot handle being served from the cloud as a web app:

• Industrial control

• Medical

• Servers themselves

• Military

• Much gaming (you play games when you're bored, why are you bored, maybe because you don't have the internet ...)

• Anything to do with managing the network itself

• Anything where latency is critical (can't beat the speed of light)

• Airgapped for security

etc. Apps in these fields don't just experience friction when trying to use the web, they experience a brick wall.

Then there are the many, many apps that struggle to ram their square pegs into the round hole of a browser, e.g. embedded devices struggle because browsers won't automatically discover them, because browsers are slowly turning the screws on requiring TLS but the TLS model doesn't really work for embedded devices you connect to locally. Developer tools. And so on and so forth.

Finally, there are other common distribution use cases browsers don't even try to support:

• Downgrading if the server ships a regression. "Regression" doesn't have to mean bug or outage, it can mean deliberate UI redesign, hence all the screaming whenever web apps change their UI layouts. Your workforce productivity can drop overnight because some SaaS shipped a new UI nobody asked for, and you're just screwed at that point. If it didn't come at a good time for your business or the new version is a downgrade for you, once again the web cordially invites you to try pounding sand. It might help you feel better.

• Apps that aren't controlled by a single organization (hence why web apps suck for the blockchain/decentralization community - Bitcoin 0.1 wasn't a web app for good reasons).

• Apps that need to keep working even if the originating organization goes bankrupt.

• Apps that need to separate data storage from software distribution. The origin concept doesn't make this easy.