I disagree it will replace it. They have different niche, REST is especially simple to implement client side and server side
With REST, there is a continuous tension between efficiently satisfying the data needs of specific clients, and keeping the number of endpoints manageable. The reason for this tension is that a server defines what data an endpoint returns, and the client merely requests it. Especially in mobile apps, the overhead of performing separate requests or of requesting extraneous data is often unacceptable, so we’re forced to add ad-hoc endpoints with custom response structures.
In some cases, yes, this might be true but this usually applies for extremely complex mobile applications that have a very good understanding of the underlying infrastructure. It’s not a big surprise that Facebook came up with this solution as its mobile application is probably one of the most complex apps out there. I don’t think the complexity required by implement a GraphQL-like interface will help a lot of APIs (two high-profile examples might be Twitter and Netflix).
Also, if the REST APIs are simple (as in “not complex”) this doesn’t mean that it’s a bad thing. On the contrary, it’s a lot easier to understand and implement a client that’s working with a REST API because the entities are so obvious and the way to query them is also very obvious.
As a counterpoint, Netflix simultaneously invented a specification called JSONGraph that is extremely similar to GraphQL, mostly because of the huge variety of clients that were all being forced to consume the same API, leading to response payloads that were optimal for none of them. The idea of client-driven query endpoints is here to stay, I think.
I think that, contrary to the linked article, both REST and GraphQL are here to stay. I believe that GraphQL might be better suited for complex API interactions while REST has (or could have) a simplicity that can be beneficial for simpler clients.
Isn’t this essentially the reason SQL was created? Describe the (strongly typed) data you want and let the database figure out how to calculate it? Is/was there an equivalent standard language for graph/OO databases? (makes note to google this later)
There isn’t one with the level of cross-vendor buy-in that SQL has in the RDBMS world. OpenCypher is one proposal for a cross-vendor graph-db query language. In the semantic-web/RDF world (which is sort of its own sub-area), SPARQL is the standard.
A major pain point with REST is evolving an API efficiently while still supporting older clients. This often leads to endpoints returning data current clients no longer need, and has the danger of inadvertently disrupting older clients. It may also make client teams dependent on backend teams, slowing down product development.
I just don’t really see this as a problem. If you are churning so much on the frontend, maybe you’re doing something weird/wrong.
This seems like a technique more to address management problems (lots of different teams that can’t play nice or avoid feature creep) by pretending they are technical problems. One could parody this by saying that having an HTTP endpoint that took raw SQL run under an API user role on the database helped let the client teams innovate without being slowed down by the backend or DBA teams.
[Comment removed by author]
Delivering long-lived, robust, backwards compatible APIs is extremely challenging.
I agree! That’s why simple APIs that are well-documented (and occasionally even non-REST) are preferable to more complicated schemes–especially ones where the client can make arbitrary queries by design.
This just seems like a fancy technology that solves a problem that Facebook has well that everybody else is kinda cargoculting.
GraphQL doesn’t inherently protect you against backward incompatibility, as he says himself later on; you still have to take care not to pull out stuff older supported clients might need. I’d argue that it’s still, potentially, a major pain point in GraphQL.
A nice plus with GraphQL is that it’s easier to see if someone’s using certain fields by looking at the queries. Your deprecation can be more granular.