GraphQL vs. REST: When to choose which one?

GraphQL has been around for five years but quite frequently it still is seen as “the new kid on the block.” When it comes to deciding if and when to choose GraphQL for an API, this decision is often framed as a choice between “GraphQL and REST.” REST in this comparison stands for resource-oriented HTTP-based APIs. This means that the question being asked contrasts two of the five API styles: It asks whether the query style is better than the resource style.

In the case of GraphQL, one interesting observation is that even Facebook, the inventor of GraphQL, only uses GraphQL for their own applications (their mobile apps and their web app), whereas the public Graph API is not based on GraphQL and is REST(ish) instead. This observation is true for GraphQL usage in general: It is a reasonable choice when looking at private APIs and tightly coupled scenarios, and this is where most GraphQL usage happens. When it comes to partner and public APIs, resource-oriented HTTP-based APIs are the most popular choice, and for a good reason.

As mentioned in the recent video and article, picking an API style (and a technology for that style) is a design choice, and, like any design choice, should be based on design considerations such as API consumers, API producers, and the API scenario. This applies to the “GraphQL vs. REST” question as well, and in the end, the most important question is how to design and deliver a good API product, and to always consider your API consumers and your landscape.