Incoherent, author states this:
It’s time to admit it: the REST-haters are right. REST does not make for a great raw data-level API architecture, and efforts like GraphQL and RPC-like architectures are likely to end up producing something more usable for complicated data needs.
Then spends the rest of the article contradicting that statement.
Also who decided Hypermedia APIs were a bad idea?
The author doesn’t talk about the importance of, um, representational state-transfer. It’s not an abstract concern - or, rather, it is an abstract concern to developers using APIs from the client side, but from the server side, it makes scaling much, much easier. It’s an important architectural feature, and I hardly foresee it going away anytime soon, although I agree that it’s legitimate to ignore it for situations where a single server or sticky sessions are sufficient.
The author is really writing about HATEOAS and other strategies where a response contains information on available further actions. That’s a nice idea, but it’s a completely different idea. I would hardly call it an idea with proven value; it is reminiscent of CORBA, but I don’t feel like CORBA managed to show it was worthwhile, either. I wish the author luck with “rescuing” it, though I’ll note that it has resurfaced often enough that it’s in no long-term danger.
I’d love to have a detailed discussion about the whole GraphQL thing, but there’s nothing to talk about this time since the mention is so brief. But I’d like to mention that query languages can be compatible with REST; the complexity of the “verb” is an orthogonal issue from how state is managed. I do realize that there are groups who feel that REST should mean, specifically, representational state transfer with only CRUD verbs, with those verbs mapped to HTTP in any of a dozen different very particular ways; that’s not how I’m using the term here.
It’s just kind of really distressing that the article’s title names one technology, and then it talks about a completely different one.