REST API and GraphQL: a comparison

To integrate applications quickly and at scale, APIs are built using protocols and/or specifications to define the semantics and syntax of transmitted messages. These specifications constitute the API architecture.

Various styles of API architecture have been published over time. Each of them has its own data exchange standardisation models. The choice raises endless debates on which architecture is best.

In this article, we discuss REST APIs and GraphQL APIs.

 

REST API

The REST or RESTful architecture is the result of a 2000 doctoral thesis by Roy Fielding, a computer scientist from the United States. His REST protocol is based on six principles:

 

1. Client-Server
2. Stateless
3. Caching
4. Uniform Interface
5. Layered System
6. Code on demand

 

Of these principles, it is above all the stateless principle that is essential for the structure of interfaces programmed with REST (REST API). This means that each REST message contains all the information necessary for understanding it. Although REST is basically compatible with any protocol or file format, the HTTP protocol is usually used. Data transmission is usually via JSON (JavaScript Object Notation).

 

Advantages:

• Interface portability to other types of platforms
• Excellent performance and scalability
• Independent development of the various components
• Easy migration to other servers or changes to the database (always respecting the correct sending of data from each request)
• Overall development flexibility
• Independence of the type of operating system, software and platform in use
• Possibility of using PHP, Java, Python or Node.js servers

 

GraphQL 

GraphQLsta per Graph Query Language ed è stato originariamente sviluppato da Facebook nel 2012 per uso interno. Nel 2015, Facebook ha rilasciato GraphQL come open source e da allora GraphQL è stato consegnato alla GraphQL Foundation, fondata appositamente per questo scopo e a sua volta supportata dalla Linux Foundation. GraphQL è una miscela di un ambiente di runtime che include librerie per diversi linguaggi di programmazione come Python, PHP, Ruby o JavaScript e un database con sintassi simile a SQL. La validità delle interrogazioni viene interrogata tramite il sistema di tipizzazione, che può identificare e autenticare l'utente con l'aiuto di voci speciali e di una struttura individuale.
La caratteristica unica di GraphQL è che il Client può specificare quali dati desidera: il server presenta una selezione di dati che possono essere interrogati e il Client decide esattamente quali dati desidera. Questo rende il tutto molto più efficiente perché non vengono trasferiti dati inutili, ma solo quelli di cui il Client ha effettivamente bisogno. 

GraphQLsta for Graph Query Language and was originally developed by Facebook in 2012 for internal use. In 2015, Facebook released GraphQL as open source and since then GraphQL has been handed over to the GraphQL Foundation, founded specifically for this purpose and in turn supported by the Linux Foundation. GraphQL is a mixture of a runtime environment that includes libraries for various programming languages such as Python, PHP, Ruby or JavaScript and a database with SQL-like syntax. The validity of queries is queried via the typing system, which can identify and authenticate the user with the help of special entries and an individual structure.
The unique feature of GraphQL is that the client can specify what data it wants: the server presents a selection of data that can be queried and the client decides exactly what data it wants. This makes it much more efficient because no unnecessary data is transferred, but only that which the client actually needs.

 

Advantages:

• Interoperability between different technologies
• Flexible customisation of APIs
• Independence from programming languages and IT infrastructures
• Direct exchange of information in database format
• Query language is standardised
• Static typing
• Easy integration into your own code with the help of libraries
• The complete runtime environment is available in open source format

 

REST vs GRAPHQL

Graphql offers some multiplexing for API calls and this is the first difference with REST. In REST we have many individual endpoints that define a resource as well as its identity and, in the simplest case, we have 4 ways to access this resource. In GraphQL, on the other hand, there is only one endpoint, which is usually called /GraphQL, and all queries can be executed through this Endpoint; mutations and the endpoint are not equated with a resource or an identity, which in GraphQL are deliberately separated from each other. However, these premises are not yet sufficient to declare a real winner, because the whole thing has its advantages and disadvantages.

Unlike REST with GraphQL there is neither over-fetching nor under-fetching. Another problem present in REST but not in GraphQL is the n+1 request problem. If I have a list of elements and then would like to have some details of the individual elements this can be expressed effectively in a single query with GraphQL. Another aspect that speaks in GraphQL's favour is the type safety that is directly integrated into the schema by default. With REST I can try to provide this via open APIs by specifying a JSON schema, but this is just an extension that is not available with all APIs. Whether the description I get via the open API actually matches the actual API is always more a matter of luck than a guarantee, and GraphQL in all this is much stricter because it is typed and standardised. 

With all these points in favour of GraphQL, is there anything left in favour of REST? Yes.

GraphQL's advantage of having only one Endpoint is at the same time also a disadvantage because I cannot perform caching as one Endpoint can be used in numerous different ways. The HTTP protocol implements a standard caching request. The absence of over- and under-fetching also has a disadvantage. It is possible that if a very large selection is specified, the server needs many resolvers. This means that many queries can be made on the database or the underlying API and then the whole thing has to be aggregated, which can prove very costly. 
The fundamental distinction in both cases: GraphQL is more functional, REST is more technical, and it cannot be said that one is right and the other wrong. Rather, it is a matter of deciding, depending on the situation, whether a GraphQL-based API or a REST-based API is useful, and it might make sense to use both in a project, taking advantage of the static typing of GraphQL and the dynamicity of REST.

 

Conclusion

There is always a tendency to create friction between technologies by always looking for a winner, today, for example, many programmers are oriented towards the use of GraphQL, whereas ten years ago, when REST replaced SOAP, the story was the reverse.

The problem with these positions is that they unilaterally self-select a technology instead of considering how its actual characteristics and peculiarities best fit the situation at hand or how to do so by integrating several technologies at the same time by evaluating them well on a case-by-case basis, which is what we do at DevInterface.

Interested in getting in touch with us? You can do so by writing to us here.