When it comes to serving web applications with an API, two of the most popular methods employed are Representational State Transfer (REST) and GraphQL. While REST has been around for a while, GraphQL was created in 2015 in order to address some of the most common problems that arose from using a RESTful architecture for accessing backend APIs.
What is REST?
Representational State Transfer, most commonly referred to as REST, is the most commonly used architecture for accessing backend APIs and serving frontend clients. In a nutshell, REST works by calling HTTP methods onto URL generated provided by the backend software. An API that conforms to REST standards is referred to as being ‘RESTful.’
A RESTful system can be broken down into three basic moving parts: 1) The database which stores all data that is to be sent to and received from the application as well as edited and changed by the application, 2) The URL endpoints which directs the application to specific locations for receiving data, sending data and changing data, and 3) The HTTP methods that are imposed upon the URL endpoints.
The above image is a commonly used diagram to explain REST in as concise a way possible. The client will contain a function or a method that will send defined HTTP method that will be one of the following: GET, POST, PUT, PATCH, or DELETE. Each of these methods performs a separate action on the API. For further detail on what each of these methods gets, click here.(https://www.restapitutorial.com/lessons/httpmethods.html)
The HTTP method must be called on an endpoint, which is generated by the backend architecture and provides either a list of objects to be seen or manipulated or a single object to be seen or manipulated. The HTTP method then either pulls or affects the objects in the API and is sent back to the client.
If the two paragraph explanation above seems simple, you now know why REST has been such a popular method of manipulating backend APIs for a very long time. REST is both easy to comprehend and easy to use and patch into applications.
GraphQL is a data querying and manipulation language that performs the same functions as REST. GraphQL can be used on a wide variety of databases in order to receive, send, change or remove objects in the API, very much similar to RESTful HTTP methods. The key difference, however, is that GraphQL does these actions by ‘querying’ the API, or sending specific messages to the API that can perform the aforementioned methods in much better detail, precision and complexity.
For example, a query can be made from your backend architecture that requests only a single value in a single object be returned. Rather than having to GET the entire object and then sift through it and return the desired value on the frontend, GraphQL can be used to only receive the specific value and the specific object that it desires. And it doesn’t just apply to single values or objects. GraphQL queries can be made to receive, send, change and remove all kinds of objects and object values using specifications of varying complexity. I’m sure you can already see the power that GraphQL can provide to your backend architecture.
There are two major problems of RESTful APIs that GraphQL solves. The first, there is no need for many URL endpoints. While RESTful APIs require different endpoints for each database, table and very often for each HTTP method, GraphQL’s querying system allows it to send instructions to the same URL endpoint in order to accomplish different actions. This saves both memory and storage space but also makes front-end developing simpler and more easily comprehensible.
The second major problem that GraphQL solves is the transferring of large amounts of data. With RESTful APIs, often times you will see frontend clients receiving full database tables only to use a single object in the table, or even a single property in the object. This is because most GET URL endpoints will send the entire database to the frontend client and leaves the job of sorting through the database up to the client. With GraphQL, there is no need to send an entire database because desired objects or tables can simply be queried and selected as they are needed. This saves computational time and application memory.
If you are using a small application that doesn’t take up too much processing power, and one that doesn’t have a need for complex API queries, you may be inclined to go with a RESTful architecture due to its simplicity. However, the more your application grows, and the more objects you are storing in your database, the need for a querying API manager like GraphQL becomes more and more apparent. For any kind of large-scale application with many different databases and/or tables and one that uses database objects in varying and novel ways on the frontend client, GraphQL is always a much more powerful option for accessing your backend API.