|
Is REST perfect? Probably not. But it certainly does its job, and that's why most middle-tier APIs these days, whether it be those that power web applications or mobile apps, are in REST, with the backend itself being written in a variety of languages (PHP, Python, Java, C#, etc). 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).