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.
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:
- Uniform Interface
- Layered System
- Code on demand
- 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
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.
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.
- 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.
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.