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
|Graph API||REST API|
|GraphAPI is an application layer server-side technology that is created by Facebook to execute queries with existing data||REST is a software architectural style defining a set of constraints for creating Web services|
|Uses client-driven architecture||Uses server-driven architecture|
|Can be organized as per schema terms||Can be arranged in terms of endpoints|
|GraphAPI is a budding community||REST has a large community|
|Known for quick and fast development||Has slow development speed|
|Difficult learning curve||Moderate learning curve|
|Identity gets separated from how you fetch it||Endpoint you call in REST is object identity|
|Provides high consistency at all platforms||Hard to get consistency across all the platforms|
|GraphAPI endpoints are single||REST API endpoints are multiple|
|Provides Consistent and high-grade UX at all operating systems||Difficult to maintain consistency at all the operating systems|
|The GraphAPI partners need customization||Offers flexible public API that easily enables new applications|
Features of GraphQL API and REST API
|Graph API||REST API|
|Statically typed creating no need to define variable prior to using it||It has a holistic interface.|
|Can decouple frontend from backend||It can scale to achieve high performance to meet up client demand|
|No over and under fetching data||Easy access of resources|
|It is language and HTTP agnostic||It enables systems to transmit and send or receive data in an easier manner|
|The documentation process is free of cost||Database resource in an application can be rapidly mapped|
|Saves a lot of bandwidth||Allows you to store frequently used information in the memory|
|Has simple and easy to understand architecture and pattern|
Pros and Cons of GraphQL API
|Gives declarative query language that is not imperative||No resources available for backend operations|
|Hierarchical and product-centric||Can’t work complex apps due to limited designs|
|Strongly typed with queries executed within the context of a particular system||Performance issues with complex queries|
|Queries encoded in the client and not in the server||Overskilling of small applications|
|Multiple features of the application layer of the OSI model||Not based on HTTP caching methodology|
|Provides a human-readable query||Need GraphQL Schema Definition language orientation before implementation|
|Easy to deal with several databases||It uses a single endpoint and does not follow the HTTP caching|
|Can fetch data with single API call||Not a viable solution for simple applications as it increases complexities|
|Provides query batching and caching|
|Tailoring requests to your needs|
|Helps discover schema in the right format|
|Auto functionality for documentation that syncs with API changes|
|Evolution possible without versioning|
|Used for rapid application prototyping|
|Can be shared to a higher component level for reuse|
|Permits to select which functions to expose and how it works|
Pros and Cons of REST API
|Enables scaling software with great ease||Does not maintain states of previous interaction between client and server|
|Performs migration from server to server easily||Need to send separate requests to API for data retrieval from two endpoints.|
|Easy protocol for different project development||Cannot get limited fields|
|Provides opportunity to try various project environments while developing it||Manipulation of nested resources is not possible|
|Very easy to build and adapt||Poor data searching facility|
|Can develop process instances explicitly||Query validation not available|
|Client machine does not require routing information||Does not handle API additions, changes and depreciations|
|Developers can create API to meet user-specific needs||No tooling or framework guidance is available|
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.
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.