What is API. Difference between Rest and GraphQL
API is an acronym for Application Programming Interface. In simple words, An API is a software component that allows two applications to talk to each other.
Similar to user interfaces APIs enable the interactions between one party and another, but unlike them they are not visible to end users. The essence of APIs is to act as a communication layer between apps and databases allowing them to exchange and manipulate data quickly and securely. And it is significant for programs which are written in different languages, so we can say that APIs help programs to overcome the “language barrier”.
Nevertheless, while the GraphQL vs. REST battle usually leans toward the first one, there are some cases where the REST API is a better choice. For example, RESTful services are more effective in terms of HTTP caching mechanisms, whereas GraphQL doesn't support browser at all and mobile caching to expedite calls.
RESTful services also make the SQL log process simpler. Developers find optimizing SQL log queries with REST relatively easy compared to GraphQL's dynamic approach.
Besides, REST APIs can use HTTP status codes to detect errors and ease the API monitoring process while GraphQL makes it difficult to handle these errors and to monitor the APIs.
Nevertheless, while the GraphQL vs. REST battle usually leans toward the first one, there are some cases where the REST API is a better choice. For example, RESTful services are more effective in terms of HTTP caching mechanisms, whereas GraphQL doesn't support browser at all and mobile caching to expedite calls.
RESTful services also make the SQL log process simpler. Developers find optimizing SQL log queries with REST relatively easy compared to GraphQL's dynamic approach.
Besides, REST APIs can use HTTP status codes to detect errors and ease the API monitoring process while GraphQL makes it difficult to handle these errors and to monitor the APIs.
To have a more prime example, API can be compared to a menu. Menus contain a list of dishes and, when someone orders one of them, the restaurant does some actions and then sends the ordered dish back. APIs define a list of commands and, when some program uses one of them, the other program performs some actions and then sends back what was requested by that command (usually some kind of data).
Besides, APIs reduce complexity. When you order food from a restaurant, many complex steps such as chopping ingredients, precise heating, boxing the food, etc. are strung together to complete your order. Imagine how irritating it would be if you needed to describe every step of cooking a dish ordered? Instead, you say the menu item and the rest happens automatically.
However the example with food ordering isn’t perfect either. When you’re placing such order, there are a lot of variations you could use to get the same result. But programs aren’t as flexible and smart as humans, so when a program is making a request, it has to be formatted in a very specific way.
This means that APIs define not only the list of commands but also the format of those commands. And when somebody releases an API for their software, it’s like they basically tell everyone: here is what you can get from our app, and here is exactly how you have to ask to get it.
Nowadays the usage of APIs has grown tremendously. Survival in the wide API economy relies on your ability to build easy-to-use APIs that other developers can exploit to get the information and resources they need from your service to expand their own.
This widespread usage of APIs showed a few downsides of how APIs were built and used, which generated such innovations as REST and GraphQL.
The RESTful architecture came out in 2000, and it offered a simple way for computers to interact with each other. This architecture makes a use of the HTTP protocol for communication between computers, and this communication is stateless. It means that the server doesn’t store any state about the client session on the server side.
In 2012 Facebook created, and in 2015 open-sourced GraphQL announcing it as an alternative to REST.
GraphQL is a query language, a specification, and a set of tools that operates over a single endpoint using HTTP. To the contrary of REST, where each resource can be identified by the URL and fetched by sending a GET request to that specific URL, API development with GraphQL needs a schema to define the resources it will be operating with.
Benefits of REST
One of the main advantages of REST is scalability. The architecture separates client and server which allows scaling programs and applications indefinitely without much difficulty.
Additionally, REST APIs offer significant flexibility. Given that data isn’t tied to resources or methods, REST can handle different types of calls and return different formats of data, which allows developers to build APIs that meet specific needs while being mindful of the needs of a diverse user base.
Benefits of GraphQL
When you are modifying the UI of your application, there’s a pretty high chance that your data requirements will be changed as well, i.e. you’ll need to fetch more or less data than before. GraphQL makes such quick product iterations on the front-end possible as it allows making changes on the client side without messing around with the server.
And since everything in GraphQL is schema-driven, extending won't be a problem as the new field won't affect the existing ones.
Besides, with GraphQL, developers have the ability to gain insight into the data requested on the back-end and how the available data is being used. This is possible because each client specifies what exact information he or she needs. And with this developers are able to improve API performance, by deprecating fields that clients no longer use.
GraphQL defines the capabilities of APIs using a strong type system that basically tells the client how data can be accessed. Both front-end and back-end teams know the structure of the data which, therefore, allows them to work independently.
GraphQL vs. REST
In general, the appeal of GraphQL comes from heightened efficiency compared with REST. RESTful services often return large amounts of unusable data mixed in with necessary information (usually it is the result of multiple server queries). And this, therefore, increases the time needed to return all the required data.
Nevertheless, while the GraphQL vs. REST battle usually leans toward the first one, there are some cases where the REST API is a better choice. For example, RESTful services are more effective in terms of HTTP caching mechanisms, whereas GraphQL doesn't support browser at all and mobile caching to expedite calls.
RESTful services also make the SQL log process simpler. Developers find optimizing SQL log queries with REST relatively easy compared to GraphQL's dynamic approach.
Besides, REST APIs can use HTTP status codes to detect errors and ease the API monitoring process while GraphQL makes it difficult to handle these errors and to monitor the APIs.
GraphQL APIs can be a hot new technology, but it is important to consider the tradeoffs before making such architectural decisions. For some APIs, for example, APIs with very few entities and relationships across entities (like analytics APIs) GraphQL is not the best option. But as the opposite, applications containing a lot of different domain objects (like e-commerce with items, orders, users, payments, etc.) you may find GraphQL more beneficial.
Actually, comparing GraphQL and REST is like comparing SQL and NoSQL databases. You may have an application where it makes sense to model complex entities in a SQL DB while there are other apps, for example, that only have “messages” where NoSQL DB will be a good choice.
on 18 May 2020