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 basics 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/:idendpoints 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 manage 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:

query GetAllPets {
pets {
name
petType
  }
}

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

mutation AddNewPet ($name: String!, $petType: PetType) {
addPet(name: $name, petType: $petType) {
id
name
petType
  }
}

Example:

Query:-
    query {
        hero {
            name
            height
            mass
         }
    }

Response:-
    {
        "hero": {
                "name": "Luke Skywalker",
                "height": 1.72,
                "mass": 77
         }
    }

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

type BlogPost {
...
}
type Author {
...
}

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.

type Blogpost {
title: String!
content: String!
}
type Author {
name: String!
}

Conclusion

GraphQL is the newborn baby in the tech world with a lot of great features and solves most of the challenges faced with REST. Neither REST nor GraphQL is a silver bullet, they both have their strengths and weaknesses. Determining the one to use as always, depends on the use cases.