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/: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 /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
HTTP Response Status Code
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 the 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.
Originally published at Reveation Labs Blog Page
