GraphQL vs. REST: Which is better suited for interface development?
CMS and shop systems are not all-round solutions for the web presence that can do everything. In view of ever more new and complex requirements, this claim would be utopian. Rather, the systems are the foundation on which an individual website can be created. For some time now, this has been realized via interfaces that allow new systems and functions to be integrated. Representational State Transfer, or REST for short, has long been the dominant standard for web APIs. With GraphQL, this is now getting competition. In this blog post, we therefore look at the similarities and differences between the two principles and clarify the question of which one is more suitable for your project.
GraphQL und REST: Ein kurzer Steckbrief
The REST or RESTful architecture is the result of a doctoral thesis by Roy Fielding, a U.S. computer scientist, from the year 2000. His REST protocol is based on six principles, whereby above all the principle of statelessness is essential for the structure of interfaces programmed with REST (REST APIs). It states that each message must contain all the information necessary for understanding. Although REST is basically compatible with any protocol or file format, the HTTP protocol is usually used. Data transfer is usually done via JSON (JavaScript Object Notation).
For more than a decade, the REST architecture would remain unrivaled as the standard for building interfaces until Facebook developed the GraphQL query language in 2012. In the meantime, this has become open source and has been handed over to the Linux Foundation. For data processing, REST and GraphQL take different paths. While REST transmits all information of a query, GraphQL wants to transmit only necessary data. For this purpose, the queries are matched with schemas created by developers, so-called resolvers then assign suitable values to the queried object types.
Reading tip: You want to learn more about how GraphQL works? Then we recommend our blog post GraphQL at OXID: More possibilities with the new API!
Advantages of GraphQL
- Targeted data retrieval: Only the data that has actually been requested is output, which prevents the occurrence of irrelevant information (no overfetching).
Little room for miscommunication: By defining the object types in GraphQL queries, it can be ruled out that the communication of client and server run past each other.
Further development without versioning: New functions can be added to an API without affecting existing queries.
No specific application structure: GraphQL can also be installed on top of an existing REST API and used through classic API management tools, such as Microsoft Azure’s API Management.
Advantages of REST
- Established approach: since REST has been used in interface programming for more than 20 years, the approach is firmly established in practice.
- Unique identification: another of Roy Fielding’s defined principles states that each resource must have a unique URL assigned to it, which makes identifying the REST API much easier.
- Unified methods: REST accesses an HTTP protocol and uses its commands, such as GET (retrieve a resource) and POST (create a resource). Because this principle always holds, the commands are the same all over the world.
GraphQL vs. REST: Which approach should you take to API programming?
The unsatisfactory answer first: It all depends. The comparatively young GraphQL approach should not be understood as a replacement for programming a REST API, but as an alternative, because both have their raison d’être.
The advantages and features of GraphQL and REST result in their areas of application. If, for example, your API is to enable a targeted data type query and be extended at any time, then GraphQL is most likely the better choice, as the query language enables particularly high-performance interfaces. Performance is also a topic that is becoming increasingly important in the e-commerce environment. Here, GraphQL can make full use of its advantages, which is why it was also decided on the part of the popular store system OXID eShop to publish an official OXID API based on the language for interface development. An official REST API, on the other hand, does not exist to this day.
One argument in favor of using REST for interface development is that the approach has been used all over the world for more than two decades. If language- and location-independent development is a priority for your project, then you should rely on REST.
ESYON: Your expert for interface development
ESYON is a certified partner for Mircosoft Dynamics, OXID eShop and Perfion. With the help of our specially developed interface solutions, we bring together the three worlds of online store, ERP and PIM. We would also be happy to support you with your project, be it project management, integration of new systems or individual development. Please contact us!
