Is REST API Dominance Decreased Due To The Emergence of GRAPH API?

GraphQL is an application layer server-side technology. Developed by Facebook, it executes queries with the existing data. With GraphQL you can optimize RESTful API calls. It provides a declarative way of fetching and updating your data and helps you load data from server to client allowing programmers to choose from various requests. REST API is a software architecture style defining a set of constraints to create web services. Designed typically to work with files, media components, and hardware devices, REST represents Representational State Transfer.

Key Differences Between GraphAPI and REST API

Features of GraphQL API and REST API

Pros and Cons of GraphQL API

Pros and Cons of REST API

Application of GraphAPI

Here are some of the important applications of using GraphQL:

• Offers relay and other client frameworks.
• Assists performance improvement of the mobile app.
• Used when the client application has to specify which fields are needed in a long query format.
• Used when you have to add functionality to your old or existing API.
• Used for simplification of complex API
• Mix and mash facade pattern, which is commonly used in object-oriented programming.
• Used to aggregate data from more than one place into one convenient API.
• Can abstract on an existing API to specify a response structure based on user needs.

Application of REST API

Below is the important applications of using REST

• Used in heterogeneous languages and environments.
• Enables web applications that are built on various programming languages to communicate with each other.
• REST helps these web applications to reside in different environments, some could be on Windows, and others could be on Linux.
• Makes the UI portable across multiple platforms.
• Obtain a uniform interface.
• Layered system in which architecture is made of hierarchical layers.

Current Scenario of REST API and the problems faced 

REST APIs are the standard choices for companies that deploy APIs and launch developer platforms. REST allows developers to work with someone else’s API and does not need any special initialization or libraries. You can simply send the requests with common software like cURL and web browsers. However, it is found that REST is much tighter coupled to HTTP and CRUD compared to SOAP, but provides loose data contracts.

In addition, more variety of APIs are introduced in production use and are scaled at extreme levels. Hence, certain problems in RESTful architecture transpired. With GraphQL taking place between SOAP and REST, it began to gain more popularity as compared to REST.

Problems With REST

Server Driven Selection

In RESTful APIs the server creates resource representation that is responded back to the client. However, if the client may wish for something data-specific, REST won’t be able to meet the expectations as compared to GraphQL which allows you to represent the queries in a much cleaner way.

Fetching multiple resources

With GraphQL you can make APIs less chatty. Many of us have seen an API where we first have to GET /user first and then fetch each friend individually via GET /user/:id/friend/:id, this can result in N+1 queries and is a well-known performance issue in API and database queries. In other words, RESTful API calls are chained to the client before the final representation can be formed for display. GraphQL can reduce this by enabling the server to aggregate the data for the client in a single query.

More in-depth analytics

API analytics is negative for GraphQL APIs as there is very little tooling out there. The tools that support GraphQL APIs provide much more insights into queries than RESTful APIs.

How is the Graph API better than the REST API to a certain extent?

Nevertheless REST APIs have become standard for designing web APIs, they have lately shown inflexibility to keep up with the quickly changing requirements of clients who access them.

And that is why GraphQL was created to cope up with the limitations of REST. It solves several shortcomings and inefficiencies that developers experience when interacting with REST APIs. Some of the major differences between REST and GraphQL when it comes to fetching data from an API can be enumerated with this simple example:

A blogging application needs to display the titles of the posts of any specific user. The same screen also displays the names of the last 3 followers of that user. How to solve such a situation with REST and GraphQL.

• Data fetching with REST vs GraphQL

With a REST API, you would typically gather the data by accessing multiple endpoints. In the example, these could be /users/<id>endpoint to fetch the initial user data. Secondly, there’s likely to be a /users/<id>/posts endpoint that returns all the posts for a user. The third endpoint will then be the /users/<id>/followers that return a list of followers per user.

With REST, you make three requests to different endpoints for getting the required data. Moreover, you are overfetching as the endpoints return additional information that is not needed. 

Whereas, in GraphQL you need to simply send a single query to the GraphQL server that includes the concrete data requirements. The server that responds with a JSON object is where these requirements are fulfilled.

With GraphQL, the client can write data specific to the exact needs in a query. The structure that the server response follows precisely follows the nested structure that is defined in the query.

• No over and under fetching

With REST the problem is regarding over and under etching. This is because the only way for a client to download data is to hit endpoints that return fixed data structures. Difficult to design the API in a manner that it is able to provide clients with their exact data needs. 

Overfetching: Download superfluous data

This means the client downloads more information than what is actually required in the app. For example, if a screen needs a display list of users only with names, REST API would usually hit the /users endpoint and receive a JSON array with user data. This response might contain information that is returned. 

Underfetching and the n+1 problem

This means a specific endpoint does not provide enough of the required information. The client needs to make additional requests for fetching everything it needs. This can escalate a situation where a client will have to first download a list of elements and then make additional requests per element to fetch the required data. 

• Frontend quick product iterations are possible

With REST APIs the endpoints are structured as per the views that you have inside your app. This is handy since it allows the client to get all required information for a particular view by simply accessing the corresponding endpoint.

However, this approach does not permit rapid iterations on the frontend. When a change is made to the UI, there is a high risk that now there is more data required than before. And consequently, the backend needs to be adjusted as well as per the new data requirements. This ruins productivity and slows down the performance of incorporating user feedback into a product.

With GraphQL, all the problems are solved. It has a flexible nature that changes on the client side and can be made without any extra work on the server. When clients specify their exact data requirement, backend engineers need not make adjustments when the design and data is required on the frontend change. 

• Backend analytics with insights

GraphQL provides fine-grained insights on data that is requested on the backend. You can get a deeper understanding of the data available by the way it is used when the client specifies accurate information it is interested in. This may evolve API and deprecate specific fields that are not requested by any clients anymore. Besides, GraphQL helps in low-level performance monitoring of the requests that are processed by your server. By using the concept of resolver functions for data collection, you get crucial insights on instrumentation and measuring performance and other bottlenecks in your system.

• Schema benefits 

GraphQL uses a strong type system to define API capabilities. All the types that are exposed in an API are written down in a schema using the GraphQL Schema Definition Language. This schema serves as the contract between the client and the server to define how a client can access the data. 

Once the schema is defined, the teams working on the frontend and backend do their work without further communication as both are aware of the established data structure that is sent over the network.

Conclusion

GraphAPI has several advantages over REST. It is faster than REST as you can seamlessly pick fields that you have to query. Moreover, GraphQL provides a better learning curve as compared to REST. Selecting GraphQL or REST is a difficult task because both are good in their way. Basically, it depends on the needs and requirements of your business. Besides, there are several similarities such as in endpoints and the list of fields available in GraphQL.