The Core Difference Between REST API and GraphQL

Introduction

APIs (Application Programming Interfaces) are software programs that give developers access to computing resources and data.

GraphQL is often touted as an alternative to REST APIs. In this section, we will look at the gap between GraphQL and REST with an example and look at how they both can synchronize and complement each other.

GraphQL is typically introduced in comparison to REST, but at this point, these comparisons are very common and cover many of the basic differences between GraphQL and REST. Instead of reiterating these points, this article will focus on a few more variation differences between GraphQL and REST.

REST API

What is REST API?

Rest is an architectural style that is based on web standards. A resource is accessed with a common interface based on the HTTP standard methods. REST allows that resource has differents representation. Example – JSON, XML etc.

An API is an application programming interface. It is a set of rules that allow programs to talk to each other. The developer creates the API on the server and allows the client to talk to it.

With REST, we may have a /authors/:id endpoints to fetch an author and another /authors/:id/posts endpoints to fetch the post of that particular author. At last, we could have a /authors/:id/posts/:id/comments endpoints that fetch the comments on the post.

Client-Server

The client-server constraint works on the concept that the server and the client should be separate from each other and allowed to evolve separately and independently.

In other words, I should be able to make changes to my mobile application without impacting either the data structure or the database design on the server. At the same time, I should be able to update the database or make changes to my server application without affecting the mobile client.

Stateless

REST APIs are stateless, meaning that calls can be made independently of one another, and each call contains all of the data necessary to complete itself successfully.

Instead, each call has the necessary data in itself, such as the API key, access token, user ID, etc. This also helps increase the API’s reliability by having all of the data necessary to make the call, instead of relying on a series of calls with server state to create an object, which may result in partial fails.

HTTP Methods

Methods	Meaning	Description
POST	INSERT	Add to an existing resource
PUT	UPDATE	Overrides existing resource
GET	SELECT	Fetches a resource. Never changed via a GET request
DELETE	DELETE	Deletes a resource

HTTP Response Status Code

Methods	Meaning
1xx	Informational Codes
2xx	Successful Codes
3xx	Redirection Codes
4xx	Client Error Code
5xx	Server Error Codes

Pros

Will scale indefinitely

High performance (especially over HTTP2)

Proven for decades

Works with any representation

Affordance-centric

Cons

Requires clients to play along

Poor or no tooling for clients

No framework or tooling guidance

Requires discipline on all sides

Challenging to keep consistency and any governance

GraphQL

What is GraphQL?

GraphQL is a query language for APIs and a runtime for managing those queries with your existing data. GraphQL provides a complete and crystal clear description of the data in your API, gives a client the potential to ask for exactly what they need and nothing more.

GraphQL is a syntax that describes what and how to ask for data and is generally used to data load from server to client. GraphQL has three main characteristics.

It lets the client specify exactly what data it needs.

It makes it easier to aggregate data from multiple sources.

It uses a type system to describe data.

Pros

Easy to start with

Easy to produce and consume

Lots of hand-holding

Contract-driven by nature

Built-in introspection

Cons

Neglects the problems of the distributed system

Query optimization

You are on your own with scaling and performance

JSON representation only

About GraphQL mutations

In GraphQL, there are only two types of operations you can perform: queries and mutations. While we use queries to fetch data, we use mutations to modify server-side data.

If queries are the GraphQL equivalent to GET calls in REST, then mutations represent the state-changing methods in REST (like DELETE, PUT, PATCH, etc).

A query to fetch all the pets from the app might look like this:

1query GetAllPets {
2  pets {
3    name
4    petType
5  }
6}
Copy

And then a mutation that adds a new pet might look a little something like this:

1mutation AddNewPet ($name: String!, $petType: PetType) {
2  addPet(name: $name, petType: $petType) {
3    id
4    name
5    petType
6  }
7}
Copy

Example:

1Query:-
2    query {
3      hero {
4        name
5        height
6        mass
7      }
8    }
9
10Response:-
11    {
12      "hero": {
13          "name": "Luke Skywalker",
14          "height": 1.72,
15          "mass": 77
16      }
17    }
Copy

Schemas

A GraphQL schema is a textual representation of your application's data graph and its functioning. Your data graph defines the entities and the relation between them. It defines a language called the Schema Definition Language (SDL) to write GraphQL schemas.

But to complete a schema, you usually need to add GraphQL operations. The GraphQL operations provide the information needed to generate and validate operations on the data graph.

Object type

Scalar type

Query type

Mutation type

1type BlogPost {
2...
3}
4
5type Author {
6...
7}
Copy

Types

Types in GraphQL are Int, Float, String, Boolean, and ID. You can add scalar types like fields to the (previously defined) object types in the schema.

The data fields for the Blogpost entities are title and content, and both are type String. If a field is mandatory, specify this with an exclamation point.

1type Blogpost {
2  title: String!
3  content: String!
4}
5
6type Author {
7  name: String!
8}
Copy