GraphQL and REST are common architectural patterns for building APIs. GraphQL is touted as an alternative to REST APIs. In this article, we will review about GraphQL and REST.
GraphQL is a query language for APIs that enables declarative data fetching to give the client the power to specify exactly the data that is needed from the API. GraphQL was developed internally by Facebook in 2012 and later, publicly released it as open source. Since then, the software development community has utilized it as one of the favourite technology stacks for developing web services. GraphQL enables you to perform three operation types: queries, mutations, and subscriptions.
A RESTful (Representational State Transfer) API is an architectural style for designing networked applications. It's based on a set of principles that describe how web standards such as HTTP, URLs, and JSON (or XML) are used for creating, updating, reading, and deleting resources.
Client-server architecture: Separation between the client and server, allowing them to evolve independently. Clients interact with the server through standardized requests.
Stateless: Each request from the client to the server must contain all necessary information to fulfill that request. The server doesn't store the client's state between requests.
Resource-Based: Resources (such as users, articles, or products) are identified by unique URIs (Uniform Resource Identifiers), and the API interacts with these resources using various HTTP methods.
Representation of Resources: Resources are represented in a specific format (like JSON or XML), and the server provides these representations to the client based on the client's request headers.
Uniform interface: The API has a uniform and standardized interface, typically using HTTP methods (GET, POST, PUT, DELETE) to perform CRUD operations on resources.
If you have an API to fetch a user's profile and their address. In REST, the request/response would look like:
The core of REST API revolves around resources. Resources are identified by URLs and request type (GET, POST, PUT, DELETE etc.).
If your API server was a GraphQL server instead, then your API calls would look like:
The response JSON is different for different "queries" sent by the client.
Request1: | Response1:
query { | {
user (id: 1) { | "user": {
id | "id": 1
} | }
} | }
----------------------------------------
Request2: | Response2:
query { | {
user (id: 1) { | "user": {
id | "id": 1
name | "name": "Elmo"
} | }
} | }
GraphQL schemas are often defined using SDL, a declarative syntax for defining types, queries, mutations, etc. The schema in GraphQL serves as a fundamental agreement or contract between the server and the client to define how a client can access the data. A schema example:
type User {
name: String!
age: Int
posts: [Post!]!
}
type Post {
title: String!
subtitle: String!
body: String!
date: String!
author: User!
}
type Query {
users: [User!]!
user(name: String!): User!
posts: [Post!]!
post(title: String!): Post!
}
type Mutation {
createUser(name: String!, age: Int): User!
createPost(title: String!, subtitle: String!, body: String!): Post!
}
While GraphQL offers several advantages, it's essential to consider its drawbacks and limitations when deciding whether to use it for a project:
While REST has been a prevalent architectural style for designing APIs, it also comes with its set of limitations and drawbacks:
GraphQL vs REST Showdown Lastly, we are going to explore the major difference between GraphQL and RESTful APIs.
Both GraphQL and REST API development lifecycle approaches are useful depending on the need, and both have their benefits and drawbacks. Both GraphQL and REST have their strengths and are suitable for different use cases. The choice depends on specific project requirements, data structures, client needs, and trade-offs in complexity, efficiency, and ease of implementation. Some projects might even use a combination of both to leverage their respective strengths in different parts of the application.
Happy Coding!