I will admit that core REST doesn't support basic "querying" functionality, or even things like pagination, filtering, sorting, etc, which is why there are a set of standards, or best practices on top of REST that aim to standardize those commonly used patterns. [1] [2] [3]
Finally REST, whether by design or not, follows the KISS principle (Keep It Simple and Stupid), and that's probably why it's gained as much traction as it has over the years.
Want to get a user object? GET /user/<id> Want to update it? POST or PUT /user/<id> Get a list of all users? GET /user/
If you look at just the "basic" examples for GraphQL, you will understand why it's never going to replace REST in its current form.
[1] Microsoft's OData: https://www.odata.org/ [2] https://www.moesif.com/blog/technical/api-design/REST-API-De... [3] https://stackoverflow.com/questions/207477/restful-url-desig...
For better of for worse as things progressed new requirements and complicating factors like the ones you mentioned (filtering, pagination, need for dynamism etc) came up that ended up being handled in a dozen different ways muddying up the waters.
To me, GraphQL built on top of REST to cover those bases and IMHO that's how these technology standards are supposed to evolve: thing comes up, it gets used till previously unknown requirements surface, new thing learning from old thing and addressing new requirements comes up.
I was really bothered when I realised that GraphQL doesn't allow for heterogeneous input-type unions though, cause that makes filtering a hassle (eg if you wanna have a query that can take an arbitrary number of filters for fields of different types).
But it's great to use though. You'll love it if you like Linq/lambda's.
/odata/Clients?$filter=Status eq 0 or LastLoggedIn is null
Working in Python-land I'm pretty confident REST wouldn't have been as ubiquitous if it wasn't for tools like Flask, marshmallow, and the myriad of other tools.
Having taken up GraphQL in personal projects I can say that at least in Python the tooling just ain't there so until it gets there I don't see GraphQL killing anything.
I'm not happy that it introduces yet another data object library, but at least it's possible to build plugins for existing ones -- SQLAlchemy and Django are already there, and it would be nice to add ones for attrs, Schematics and of course the 3.7 native data classes.
Regarding the popularity of REST -- even if it wasn't intended for CRUD originally, it fits perfectly with that paradigm, and I think this is why many people were able to implement it easily when they started using it.
Moreover, the community around it in both its GitHub and StackOverflow isn't as active as the equivalent GraphQL communities in other languages/ecosystems.
All in all I believe that increased adoption of GraphQL will lead to even better tooling and I'm sincerely hoping it'll catch on :).
My primary 'beef' with REST has always been the "10 ways to do 1 thing" especially when it comes to less standardised features like pagination, type-definition/validation, etc. GraphQL introducing some of these things out-of-the-box would hopefully reduce the comfort-zone-based bikeshedding that comes with any new REST API being developed.
I quickly learned why Django rest framework is the defacto standard... The tooling is just uncomparibly better
I haven't seen anything that would make me advise GraphQL over REST, specially now that REST tooling is finally catching up with validation and graphical generation.
All the presentations I have seen about how productive GraphQL is, seem to live in JavaScript with NoSQL databases silos.
Maybe people will stop using REST APIs, but REST will still be a thing as long as HTTP is.
GraphQL seems like it can solve some pain points of REST once you start using REST APIs at a massive scale. REST improves on SOAP in even the tiniest of cases.
I'm still aware of heaps of SOAP APIs, especially in more niche industries, where porting to REST must not have been in the budget :D.
