Technical Differences Between REST and GraphQL
- Patricia Donohue
This document is a short companion to About GraphQL API to highlight some of the differences between REST and GraphQL API technology.
REST vs GraphQL
Components of GraphQL:
Has a schema
Uses some different terms from REST (i.e. “mutation” to perform CRUD operations (i.e. POST in REST); “query” instead of GET, etc.)
Different approach from REST (more work is done on the server side instead of the front end)
REST has been the standard for designing web APIs for the last decade. It is:
Popular way for client’s to retrieve data using HTTP
Introduced ideas like stateless server and structured resource access
Has a strict specification for how servers will make data available, but in practice has been widely interpreted/implemented
Why Choose GraphQL Over REST?
The table below captures high-level reasons GraphQL has benefits that surpass REST. The Blogging App example in the section below will illustrate some of the reasons mentioned.
GraphQL | REST API |
No over/under data fetching | Over/under fetching of data as REST endpoints are pre-defined data sets (the first returns more data than is needed; the second requires multiple requests) |
Client-side changes don’t require any extra work on the server side | It is common to structure endpoints according to your app’s views--but this doesn’t allow for rapid front-end iterations, keeping the API backend current with the front-end view |
API evolution gets an assist from ability to view granular data requests, which provides input to allow field deprecation |
|
Low level performance monitoring via GraphQL’s measurable resolver functions--collect data requested by a client |
|
Strong type system used to define API’s capabilities:
|
|
Technical Differences Between REST and GraphQL
REST | GraphQL |
Data loads from specific endpoints. | Data loads from a single endpoint. |
Each endpoint has a set structure of the info it returns. | The structure of the data returned is not fixed. |
A client’s data requirements are encoded in the URL it connects to (i.e. ../co | The client decides which data it needs and must send more information to the server (than REST) to get what it needs in the form of a query. |
Example: Blogging App with REST
An example mobile web app where we want to show a blogger’s name, their blog post titles, and their three most recent followers’ names, that data for those items is displayed in three different endpoints in a REST design:
The work that is done to display this data is done in three separate calls, each retrieving more information than is actually needed than we want to display in our UI (using up data on the user’s plan):
Get the User’s name from the id resource:
2. Now that we have the user’s ID, we can GET their post titles from the posts resource:
3. Finally we do a GET on the user’s followers resource to get their names; note that we get a lot more info than just their names
Example: Blogging App with GraphQL
In GraphQL all clients could access the same information in the example above (user name, user’s blog post titles, user’s most recent three followers) via one endpoint instead of three.
You will make a single request to the server and the server will return all the information that you need.
Send a POST request to the server in which the request body includes a query that describes all the client’s data requirements.
GraphQL Request
2. The server resolves that query, retrieves the data from the database, packages it into a JSON object, and sends it back to the client.
GraphQL Response
The “data” in the response body is the “root field,” which is taken directly from the GraphQL Spec:
4. You can now use all the information returned in the JSON object to render it on the UI screen.