REST vs GraphQL APIs – A Comprehensive Comparison | HostKicker
Since its introduction by Facebook, the world of APIs is up in a storm due to GraphQL. It was introduced as an alternative to REST APIs and it fixes a lot of the problems the developers, as well as the users of API, have found with the architecture of REST. But it also introduces some new obstructions as well as challenges that need evaluation. GraphQL does not serve as an evolutionary step to the REST API. Let us look at some of the pros and cons of each of these in order to have an understanding of both when developing an application.
A Brief History
RCP, COBRA, SOAP and other protocols that were not very open were in use before the introduction of the REST API. Many of the APIs used before REST required to access, usage and understanding of complex client libraries in order to work with serialization and the deserialization of the payload in the wire. The main difference between the APIs being used today and those that were used before is that SOAPis typed strongly and marks the use of formula contracts through the Web Services Description Language.
This can have a deep impact on interoperability. Even the removal of a 32-bit integer restriction in order to accept a 64 bit long can mean breaking of upstream clients. Rather than architecture, SOAP works as a fully implemented protocol that is capable of security as well as error handling along with ACID transactions. The complexity generally arises due to the presence of several layers of abstraction put into SOAP. SOAP has the ability to run HTTP, UDP, TCP and many other protocols. The implementation of the protocols enables SOAP to have abstraction but the data layer and the application layer has a contract between the client and the server that is rigid and leads to a tight coupling between both.
The architecture of REST was first released in 2000, and it served as a simpler method for enabling communication between 2 machines with the help of the ubiquitous HTTP protocol. It did not require any additional layers to be present in a stateless or type-free way. With this, the systems were able to work as loosely coupled pairs, and were more forgiving on the changes in contract between systems and companies.
REST Today
REST APIs today serve as the standard tool that companies are using for the deployment of API and the launching of developer platforms. What makes REST special is that a developer who is working with an API designed by someone else will not have to work on initializing the libraries. A request can be sent through common software like web browsers or cURLs.
REST API makes use of the HTTP conventions and standard CRUD HTTP verbs. It is also data resource centred instead of fighting HTTP resources. This means that an e-commerce site and bank would function in very similar ways if their resources are similar. Both the entities would require CRUD operations to be performed on the resource and keep the queries cached.
A third-party developer who is new to an API will have to reason about the models of the data used and can leave the grunt work to the HTTP conventions. They would not have to dig deep into a large number of operations. This means that REST is tightly coupled with HTTP and CRUD when compared to SOAP and it makes loose data contracts available.
Problems With REST
A large variety of APIs are being placed into production use and are scaled to extremely high levels, but this has also given rise to some flaws in the architecture or the REST API. GraphQL has often been considered as lying between REST and SOAP, borrowing features from both.
Server Driven Selection:
The REST APIs has the server create a representation of the required resource and that is used to respond to the client. If the client requires a specific resource, like the name of a friend of a friend of a user whose job is engineering, the similar query in GraphQL is much cleaner than in REST.
Fetching Multiple Resources:
A major benefit of GraphQL is that it makes the APIs less chatty. Many developers face the problem where they have to first use a GET statement and then fetch each individual item through a different GET command, which results in the number of queries being N+1. This is quite a known problem with using database queries and APIs. This means that the calls from a REST API are chained onto the client before the formation of the final representation that can be displayed. GraphQL on the other hand reduces this problem by letting the server aggregate data for the client by the use of one single query.
More In-Depth Analytics:
The analytics of the API may be negative when considering GraphQL because of the presence of very little tooling. The tools that give their support to GraphQL are able to provide greater insight into the queries when compared to REST.
Problems With GraphQL
Caching:
This function is built into HTTP specification and the REST API is capable of leveraging it. When it comes to POST vs GET semantics relating to caching, they are very well defined and enable caching in browsers, enable intermediate proxies, and follow server frameworks. A GET request can stay in the history of the browser, can be cached, it can also be bookmarked. A GET request is idempotent.
GraphQL does not follow the specifications of HTTP for the purpose of caching. It instead makes use of a single endpoint. This means that it is up to the developer to ensure that caching is being implemented and that it is correct for queries that are immutable, the queries that can be cached. It requires the use of the correct key for the cache to include and inspect the content of the body.
While developers can make use of tools such as Dataloader or Relay that can build an understanding of the semantics of GraphQL, it does not cover many things such as caching in mobiles and browsers.
Diminishes Shared Nothing Architecture:
An advantage of REST API is that it complements shared architecture very well. Two endpoints publically look like two different resources under REST. Internally those two points are considered microservices that exist on isolated compute clusters. Scala is used to writing the search service and NodeJS is used in the alerting service. The HTTP routing requests are complex and the Host or the URL has lower inspection in GraphQL query and is capable of performing multiple joins.
Exposed For Arbitrary Requests:
Enabling clients to make a query for only the data that is required is considered one of the main benefits of GraphQL. This can also give rise to a problem when there is an open API such that it cannot be controlled by an organization or a 3rd party client making a query. It requires care to be taken for ensuring that GraphQL does not lead to a join query that is expensive with the potential to bring down the performance of the server or DDoS the server. On the other hand, REST API can manage constraints for matching the data model and indexing that is in use.
Rigidness Of Queries:
The ability to make custom query DSLs or the side effect operations that can be performed on top of an API are removed in GraphQL. The Elasticsearch API falls under the RESTful API and also contains a powerful DSL for performing advanced metric calculations and aggregations. Similar aggregation queries can be more difficult to model using GraphQL.
Non Existent Monitoring:
HTTP specifics are followed by REST APIs in respect to resources such as websites. This simply implies that the tools can be useful in probing a URL. In the case of GraphQL, a developer will not be able to leverage tools unless they support them by placing a query as a parameter URL. Most pings do not support request bodies or HTTP.
Apart from ping services, there are few open sources or SaaS tools that support the analytics API or even deeper analysis of the developer API calls. 200 OK is used for the representation of client-side errors in GraphQL. 400 errors will all not work on existing tools that expect it, meaning that a developer can miss the errors happening in their API. But it is more flexible at the same time, giving clients more tools for catching and understanding problems with the developer API.
Conclusion
GraphQL APIs come as exciting new technology but it is equally important to understand its trade-offs before making a decision on your architecture. APIs that have few entities and relations and entities that are analytics APIs may not be well suited for GraphQL. But applications that have a large number of different object domains such as in e-commerce where a developer will use items, orders, users, payments etc, can use GraphQL well.
Comparing GraphQL and REST is similar to making a comparison between NoSQL and SQL technologies. It makes sense to model the complex entities of a SQL database in certain applications. In other applications, you may have messages in high volumes, chat app analytics may be needed and Cassandra can be helpful.