Understand the core differences between REST and GraphQL when designing APIs, and consider four simple points to help you decide between these options.
Origins in a Facebook Case Study
In order to better understand the “REST vs. GraphQL” debate, it is useful to look at where GraphQL originates. GraphQL began when Facebook observed that the HTTP-based API powering their UIs was too chatty and did not allow more specific requests in efforts to avoid overfetching. This prompted Facebook to return to the drawing board and modify its internal API.
One overhaul option for their internal API, which connects Facebook apps on the phone and in the browser to their back-end, would have been to change the design of the REST API (resource-oriented HTTP-based API). They could have created more coarse-grained resources with additional filtering capabilities. However, Facebook chose an entirely different API style and created the query-style GraphQL language as an alternative.
It is interesting to consider that even today, Facebook uses GraphQL only for their internal API to connect their own front- and back-ends. The public Facebook APIs are still resource-oriented REST APIs.
The Four Considerations
There are various situations today where users will be choosing between REST and GraphQL. Which one is the right choice for you?
As is the nature of design, that question lacks one definitively correct answer. After all, “design depends largely on constraints”. But it’s interesting to debate which considerations, your constraints, are most relevant when choosing between the two options.
These four considerations provide a useful starting point for that decision:
- Understanding the API landscape
- Processing the data or workflows
- Listening to consumers
- Designing APIs properly
Understanding the API Landscape
Your API will not often exist in isolation. It is part of a larger API landscape. Consider how your API fits into that environment, and how both your own and the overall field may evolve.
Data or Workflows
Some APIs are more data-centric and primarily provide access to data. GraphQL can be an appropriate choice in that instance.
Other APIs are more workflow-centric, allowing users to have process-oriented conversations with the API. REST will often serve as the better option in this scenario.
Listen to Consumers
APIs are designed and provided for consumers, so it is important to think about who will be using the API. GraphQL was designed to be used as an API between UIs and APIs in data-centric settings, and it can be a good choice for that situation.
Design APIs Properly
Don’t let your choice be dictated by the tools or whichever method is easiest to create an API. The primary concern should always be to design an API that interacts with a capability, and to make sure that it is designed with the end-users in mind.