The Moment of Glory for GraphQL or Is It Time to Enjoy the REST

Whenever you discuss building network applications, the term REST will inevitably come up at one point or another. A large number of applications are built using RESTful APIs – application programming interfaces based on the REST principles. However, in the past couple of years, we’ve been hearing the term GraphQL in the same context. Looking closer, we will find hot discussions on which of the two is better and where either of them can be used with the most optimal results.

We will also take our shot at comparing GraphQL vs REST and analyzing their specifics, advantages and disadvantages.

Let’s start with looking under the hood of each of these concepts.


What is REST?

REST stands for Representational State Transfer and is a style of client-server communication over the HTTP protocol. Many network applications using communication between clients and servers are built on the basis of RESTful APIs which modify data by sending requests between the client and the server. A RESTful API can create, read, update and delete data which covers all the basic functions required for a network application. For the purposes of RESTful APIs, data is represented in the form of resources – identifiable entities of various kinds. To modify a resource, a request is made to such resource’s URI (Uniform Resource Identifier).

In REST, the request name defines the action to be performed on the target resource. For example, GET requests are used to retrieve data and POST requests – to create data.

A successful API request returns the response either confirming the action or containing the requested data. The response is usually in JSON or XML format, JSON being the default option.

The figure below shows a sample request retrieving a user’s profile on LinkedIn and the response containing the user data:


[Image source: LinkedIn Developers]

And what is GraphQL?

Its appearance is a classic story of people looking for a tool to satisfy their requirements and, failing to find one, making their own. GraphQL is a brainchild of a Facebook developers’ team that has been working on its mobile application. They tried to embed REST API within their application, however, the result was far from satisfactory. REST responses returned either too much data or too little. In both cases, the application performance was affected, and, so the Facebook guys worked out a new API which returned exactly the amount of data which was requested.

GraphQL is a data query language using two types of requests – queries (read operations retrieving data from the server) and mutations (write operations modifying data on the server). GraphQL is based on JSON syntax with the request and the response containing exactly the same fields:


[Image source: Facebook Code]

Such format, on one hand, allows predicting the data to be returned in the response and, on the other hand, structuring the request correctly, if you know what you expect to obtain. The response never contains more data than requested, which improves the application performance. And, the last but not the least, such format is easy to learn which is a great advantage in the current crazy world of different languages, syntaxes and schemas.

Pros and Cons of GraphQL and REST

Let’s summarize the advantages and disadvantages of GraphQL and REST to see where they can be used for the maximum benefit.




Supported formatJSON, XMLJSON
Communication protocolHTTPHTTP
Definition of data to be returnedServer sideClient side
EndpointsMultiple endpoints required to return data of related resourcesSingle endpoint can return data of related resources, if their relationships are defined
Data typingWeak. Data types do not need to be defined explicitlyStrong. Data type needs to be declared explicitly
Client-server relationshipThin client – fat serverFat client – fat server
Automatic documentingNoYes

Side-by-side comparison of operating principles

What can these differences mean from the practical point of view?

  • GraphQL’s ability to define data on the client side ensures that there will be no data over-fetching or under-fetching. The request will return the required data with no need to make additional queries. With REST, the scope of data to be returned is defined on the sever side which may cause the response to contain either excessive irrelevant data or not enough data
  • When relations between resources are clearly defined, a single GraphQL request involving a single endpoint will process multiple resources. In a similar situation, REST requires a separate endpoint for each resource, thus needing several queries. In terms of performance, GraphQL is more optimal than REST, as one large query is executed quicker than several smaller ones. However, this may also become the disadvantage of GraphQL, as when the application becomes more complex, large queries with nested resources may overload the server and affect the application performance
  • Strong typing enables compatibility between applications built using GraphQL. REST, having no requirement for explicit declaration of data types, cannot ensure smooth changing between applications, even if they are built on the basis of RESTful APIs
  • REST uses thin client shifting a heavier load of data processing to the server. In its turn, GraphQL balances the data processing almost equally between the client and the server. This has a positive effect on the performance of GraphQL-based applications vs REST-based ones, as less server resources are used in query processing. Of course, such relationship requires adequate client capacity to process the data
  • REST has no native documenting functionality and has to use external solutions, such as Swagger. GraphQL, on the other hand, is self-describing, which is essential for compatibility with third-party applications as well as for the API introduction to users and developers

graphql vs rest comparison


In view of the above, it’s not easy to say that GraphQL is better than REST or vice versa. Both have their advantages and disadvantages, however, it will be safe to say that for small, simple applications, REST will be a perfect choice. And when the application grows to a size where the relationships between resources become too complicated, REST may show suboptimal performance. For complex applications with large multilayered structure like social media or networking apps, GraphQL can be a good solution for its inherent ability to process data of multiple interrelated resources without performance losses.

GraphQL was publicly released in 2015, and in the past two years has managed to cause a stir in the developers’ community. In addition to Facebook, its “founding father”, quite a number of well-reputed companies, such as Coursera or Pinterest, have started to use GraphQL for building their applications. At the same time, it will be fair to say that REST sticks to its guns and remains the API of choice for such global giants as LinkedIn and Instagram.

So, it’s still too early to say that REST is past its prime, since many still regard it as a reliable and convenient tool for creating network applications. However, with applications becoming increasingly more complex and resource-consuming, GraphQL has promptly found its niche and continues to expand its popularity. And after its announcement as open-source, its chances at improvement and enhancement multiply.

↑ Go up

Similar post