This sounds like incompetent back-end design in the initial REST API. I never thought GraphQL would be more performant than REST-API + optimized queries. I don't have any experience with the current set of GraphQL libraries, but I've assumed that GraphQL is a solution to a completely different set of issues but with a possible performance penalty.
Yep, you are right - I think our previous implementation would be better described as a "typical HTTP Rails JSON API." As I briefly alluded in the article, we actually initially had a hypertext-driven API using RFC 6570 URI templates, but had to eventually change designs to increase performance for mobile apps. Payloads needed to be smaller and we couldn't afford the extra requests necessary to traverse the endpoints.
But yes, I agree, what is commonly called "REST" isn't usually.
I'm as cautious about GraphQL as one can get but I believe the greatest failure of REST is that it is unable to set clear rules and boundaries as to what is REST and what is NOT REST. I want to see a canonical implementation of what an ideal REST architecture is. Never saw one. GraphQL has clear spec which makes implementation easy. REST is at best a set of vague ideas and I understand why a lot of developers do not like that. because I don't.
> I believe the greatest failure of REST is that it is unable to set clear rules and boundaries as to what is REST and what is NOT REST.
It hasn't failed in this. The principles are very unambiguous. The problem is that people don't actually read the source material and just follow crappy tutorials and ape other systems without understanding what REST is. Then they go on to build things that aren't REST, they go on to write crappy tutorials themselves, and everybody learning from them and aping their systems fail just as badly. The problem is not clarity of communication, it's bad PR.
> I want to see a canonical implementation of what an ideal REST architecture is. Never saw one.
You're using a pretty good example right now. The World-Wide Web is an implementation of the REST architecture. It's not perfect, but it's the archetype REST was born from.
> REST is at best a set of vague ideas and I understand why a lot of developers do not like that. because I don't.
Look, it's really not difficult to find the concrete, unambiguous description of REST. It's right here:
All you had to do was Google it or look at the Wikipedia page. There is nothing vague about it whatsoever. The problem is not that REST is vague, the problem is people just don't bother reading the source material.
