> If you only want a subset of that graph, make an endpoint around that subset.

This is one of the places this article didn't ring true for me. GraphQL is a much simpler way to do this. I shouldn't have to make a new endpoint every time my frontend team adds a new screen or modal.

> Facebook is just Facebook. It's just another web company, making a ton of money off fundamental backbone technologies which it barely understands.

Like Google, Facebook is so large that it can redefine web technology. After all, the web is built upon agreed-upon standards. If enough of the web (and, yes, it can be just a few companies) agree on a standard, then that's what the web becomes.

And Facebook could very well be managing the most complicated internet-connected infrastructure on the planet. My mind is routinely boggled by the fact that Facebook loads as quickly as it does.

> You can answer every complaint Facebook has with "just use REST correctly."

Even if I use REST correctly (which I do for some reason), what benefit does that give me? My users probably won't. It adds headaches for me.

I recently wrote a compliant REST API, and our app developer told me that one of his libraries wasn't making non-POST requests properly and that I should allow all requests to be POST. What am I supposed to do about that? I couldn't rewrite a library for a platform I don't understand, and it was too late to fire him. I just broke the REST compliance of my API and moved on with my life.

The bottom line is that REST is too poorly understood and poorly adopted to offer me much benefit in terms of efficiency. Ever used a REST client library? It requires tons of configuration to tell it how the API you're consuming is non-compliant. It hardly saves time at all.

My guess would be incompetent. Just like react.native was billed as "fixing" problems with MVC, when what it offers is exactly MVC.