Your article is misrepresenting what REST API's can and can't do.
REST is all about designing for your particular access patterns. A lot of the problems you mention are around implementation and API design and they're not a limitation of the technology used. Granted, there's more work involved.
Date under/over fetching is an API design and implementation problem that can be solved. You need to only return specific attributes? You can design a query parameter that enables you to specify attributes you want returned.
Batch requests, again this is API design. You need an access pattern that covers specific dashboard data coming from multiple micro services or multiple sources? You can just create an API that bundles the data and returns it in 1 request.
Documentation on how to use an API ? How to effectively collaborate between front-end and/or back-end teams? You've heard of OpenAPI? it solves these problems and more.
sure it has a websocket build in and you can get an interface build quite quickly. That wasn't the point of my argument.
It's fine to be critical of REST API's, but do come up with arguments that make sense.
What part doesn't make sense? I was saying that GraphQL is over-engineered solution for simple use cases. REST do have a big problem of over-fetching and under-fetching. You can't just solve it by returning only specific attributes. I guess you haven't worked at the Enterprise level application that's why you don't understand the use cases where GraphQL is necessary
Engineering Manager with a passion for web and application development. Speaker and writer on work experiences and software development. Dog dad and musician fueled by coffee.
I don't know why my notifications didn't let me know about your reply. I agree that my post is extremely brief in outlining REST API limitations as that wasn't the focal point. You are correct in saying it is an implementation problem and not necessarily a problem with REST itself. GraphQL is built upon REST so to say REST is problematic was not my intent. Classic implementations on the other hand can lead to the problems outlined. You do mention some possible solutions to the problems I've highlighted, but what I've found in several organizations is that it's more of an effort to accomplish proper communication and design across teams. I have heard of several of the tools you've mentioned, such as OpenAPI, and it does solve the problem mentioned. However, it's not something that ships out-of-the-box with the tool itself and leads to extra engineering effort to accomplish the same goals. My point with the "Traditional API Problems" section of this article was to highlight the utilities and problems that GraphQL can solve out-of-the-box without extra effort to help those looking to convince their teams identify some key argument points that may resonant. These same arguments were ones that some of my previous organizations had used to make the choice to opt into GraphQL and move away from traditional REST.
Depending on what your use case is and what you're trying to accomplish, GraphQL may not be the proper solution for you. My hope is this highlights some of the arguments for possibly adopting GraphQL with your teams and gives some insight into an approach you can take in order to possibly transition if that's something you're looking to do.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Your article is misrepresenting what REST API's can and can't do.
REST is all about designing for your particular access patterns. A lot of the problems you mention are around implementation and API design and they're not a limitation of the technology used. Granted, there's more work involved.
Date under/over fetching is an API design and implementation problem that can be solved. You need to only return specific attributes? You can design a query parameter that enables you to specify attributes you want returned.
Batch requests, again this is API design. You need an access pattern that covers specific dashboard data coming from multiple micro services or multiple sources? You can just create an API that bundles the data and returns it in 1 request.
Documentation on how to use an API ? How to effectively collaborate between front-end and/or back-end teams? You've heard of OpenAPI? it solves these problems and more.
GraphQL has its own advantage over REST, having said that, I must say GraphQL is overengineered solution for simple use cases.
sure it has a websocket build in and you can get an interface build quite quickly. That wasn't the point of my argument.
It's fine to be critical of REST API's, but do come up with arguments that make sense.
What part doesn't make sense? I was saying that GraphQL is over-engineered solution for simple use cases. REST do have a big problem of over-fetching and under-fetching. You can't just solve it by returning only specific attributes. I guess you haven't worked at the Enterprise level application that's why you don't understand the use cases where GraphQL is necessary
If you want an argument then don't start by assuming what i do and do not know.
Second, I was referring to the article that misrepresents what a REST API is.
I don't know why my notifications didn't let me know about your reply. I agree that my post is extremely brief in outlining REST API limitations as that wasn't the focal point. You are correct in saying it is an implementation problem and not necessarily a problem with REST itself. GraphQL is built upon REST so to say REST is problematic was not my intent. Classic implementations on the other hand can lead to the problems outlined. You do mention some possible solutions to the problems I've highlighted, but what I've found in several organizations is that it's more of an effort to accomplish proper communication and design across teams. I have heard of several of the tools you've mentioned, such as OpenAPI, and it does solve the problem mentioned. However, it's not something that ships out-of-the-box with the tool itself and leads to extra engineering effort to accomplish the same goals. My point with the "Traditional API Problems" section of this article was to highlight the utilities and problems that GraphQL can solve out-of-the-box without extra effort to help those looking to convince their teams identify some key argument points that may resonant. These same arguments were ones that some of my previous organizations had used to make the choice to opt into GraphQL and move away from traditional REST.
Depending on what your use case is and what you're trying to accomplish, GraphQL may not be the proper solution for you. My hope is this highlights some of the arguments for possibly adopting GraphQL with your teams and gives some insight into an approach you can take in order to possibly transition if that's something you're looking to do.