Let’s have a quick gander at what GraphQL and REST API means, and the new opportunities presented by GraphQL.
Over the past year, REST became the standard for designing APIs (Application Programming Interface). Because it offered a connection to stateless servers and structured access to resources, many developers used it. However, it is can be too inflexible. It has not kept up with the demand because of the rapid changes in requirements.
To overcome the inflexibility of REST APIs, GraphQL was developed. It solves many of the shortcomings and inefficiencies that developers experience.
What is GraphQL?
GraphQL is a query language.
This query language is mainly used in APIs and to fulfil queries with the existing data. It provides a complete and understandable description of the data in the API.
Furthermore, this architecture gives the clients the power to request what exactly they require.
In other words, it makes it much easier to evolve with time. Not just that, it also enables many powerful developer tools to create.
What is the REST API?
REST is an acronym for REpresentational State Transfer.
It is an architectural style for distributed hypermedia systems.
REST is a resource.
REST uses a resource identifier to identify the particular resource involved in an interaction between components.
The state of the resource at any particular time is known as resource representation. A representation consists of data. Together with that, there are metadata and hypermedia links. These metadata and links can help the clients to transit to the next desired state.
A RESTful API looks like hypertext.
Another important thing associated with REST is resource methods to be used to perform the desired transition.
However, REST and HTTP are not the same.
Limitations in REST API
- One of the main limitations is the round trips. REST API does not provide all the required data in one request. Therefore it is required to do multiple trips to access all the data.
- Over and Under fetching, this means requests data will return fixed data structures at any given point. Over-fetching is when the client gets more information than they require. Under-fetching is when the return data doesn’t provide all of the required information.
In GraphQL, you have to send a single query to the server that includes the concrete data requirements. Then the server responds with the fulfilled requirements.
The reason behind it is because it is designed to be a more flexible solution when it comes to API architecture.
Additionally, the requests can be tailored to match the exact requirement.
- A better solution for complex systems and micro-services
- Can fetch data with a single API call
- No over- and under-fetching problems
- Tailored requests to the requirement
- Validation and type checking (which comes out-of-the-box)
- Autogenerating API documentation
- API evolution without versioning
- Rapid application prototyping
Even though GraphQL has more benefits there are some limitations. One of the main issues is the performance issue when it comes to complex queries. In addition to the performance issues, it does not handle file uploading.
Furthermore, web caching might be a problem. However, it can be optimised by using libraries built on top of it.
Yes, it is an overkill for a small application.
In conclusion, GraphQL and REST are two approaches to API architecture. GraphQL certainly has many advantages over REST but you should consider your project size / complexity before usage.
You can not just implement an API architecture given that it has more advantages. You will need to consider many factors, understand the limitation beforehand.
If you want to learn more about GraphQL and wish to develop this architecture to your application, have a look at the documentation.
Or, if you already have an API that is not functioning as expected and needs a consultation. Feel free to contact us. We at Fonseka Innovations have completed many APIs small to a larger scale.
Got any more ideas about GraphQL and REST APIs? Please post them in the comments.