> <i>If you only want a subset of that graph, make an endpoint around that subset.</i><p>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.<p>> <i>Facebook is just Facebook. It's just another web company, making a ton of money off fundamental backbone technologies which it barely understands.</i><p>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.<p>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.<p>> <i>You can answer every complaint Facebook has with "just use REST correctly."</i><p>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.<p>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.<p>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.