You're taking an extremely aggressive tone, which is not only extremely unpleasant, but also does not, in my experience, characterize a person as someone who actually knows what he is talking about. Otherwise you wouldn't be so defensive and eager to resort to accusing others of incompetence.

Let's break down the actual substance you are presenting.

> [Ordering a pizza, hailing an Uber, subscribing to YouTube channels, and updating parameters for Netflix recommendations are] three POSTs and a PUT, with the appropriate content types; absolute bread-and-butter RESTful interactions.

Sure, it's easy to represent them this way. (Although even here, this can be a little wobbly: for instance, depending on how I would model a recommendations engine, a PATCH might be more appropriate than a POST or a PUT if I'm merely updating some of the parameters rather than rewriting them all whole-hog.) Content-type aside, I would also use the POST verb as a bare minimum for these operations.

> If you can’t see how to...

I can see how to do that. What I can't see is why I should adopt what seems to me like an unnecessary and unnatural abstraction, other than some jerk on the internet abusing me over it. (Which, to answer another question of yours, is analogous to what Yegge is ranting about.)

Even if that abstraction serves some purpose in the abstract, the sheer reality is that most tooling and most developers don't slavishly follow it. That leaves me with two choices: bitterly abuse people who write API's that aren't compliant with the abstraction, or simply follow working examples, even those examples are effectively RPC-over-HTTP-with-JSON-payloads.

> Because, get this: what’s important is not the REST/RPC in the middle; it’s the state that exists at each end. And in the wonderful unpredictable hell that is non-deterministic computing, unless your management over time of all that distributed replicated state is solid as rock then your customers’ information WILL go to fuck.

Agreed. But, as you yourself point out, most people don't follow true REST, and many of them manage to get things working.

> Frankly, the only thing ad-hoc RPC really does is enable lazy irresponsible incompetent coders to ship lazy irresponsible incompetent code that flings shit all over the world with absolutely zero effort. Having had to deal with other web apps’ RPC APIs in the past, I can confirm. They’re a bunch of fucking punks.

I'm not advocating incompetence. If you're using HTTP, use HTTP verbs properly and use HTTP status codes as-properly-as-feasible. Design your endpoints to be as-idempotent-as-feasible. If you want to commit to RPC, use a well-considered RPC framework like gRPC.

> At least expressing all interactions as state changes on a remote graph forces you to think in terms of state machines, and ensures a clear and complete set of rules for telling you to go 40x yourself when—whether through idiocy, malice, or the simple inherent reality of race/lock conditions—your request tries to fuck things up.

It's not clear to me that REST is either necessary nor sufficient to solve all the problems inherent in distributed systems. Can you express your case for it in non-abusive terms?

> Plus, if everyone’s following a common set of UX/UI patterns, after a while you can likely pull out a whole lot of reusable data formats that everyone can now adopt.

Can you clarify what you're trying to get at here?

> There’s one reference that matters here, and this is it:
https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...

Yes, I'm aware of these. Can you clarify how they apply?

> Normally I’d suggest that you’ve failed to see the forest for the trees, but I suspect in your case it’s because you’re standing in the ocean.

This is just uncalled for.