Introduction

The usage of APIs has seen a tremendous growth. As mobile apps became more popular,
there was an obvious need to de-link the backend of the application from the front-end. Using
APIs as the backend made developing and launching mobile apps easier.

This important development made its entry in the web app development space too, as client-
server model became more popular here. Once again, APIs were the important components in
the server-end.

The result of all these is that APIs are now present in most of the software that are developed
nowadays. This widespread usage of APIs also showed a few drawbacks in how APIs were
built and consumed, which spawned innovations like REST and GraphQL. In this guide, we
compare the two, so that you can make an informed decision.

https://devathon.com/blog/graphql-vs-or-rest/
A brief history of how REST and GraphQL emerged
Before REST
We had protocols like RPC, SOAP, and CORBA before it became a standard to use RESTful
APIs. Using these protocols involved several complexities, e.g., if you used CORBA, then any
update to the interface required changes to both the client and server.

Protocols prior to REST required complex client libraries, which would help in serialize or
deserialize the payload in an API. E.g., SOAP uses Web Services Description Language (WSDL),
and this reduces its interoperability. If you had to implement SOAP, then you had to implement
a complete protocol including error handling, security etc.

In summary, the protocols prior to REST had rigid contracts between the client and server, and
any minor change required all clients to upgrade at once. This increased the complexities in
building and consuming APIs.

https://devathon.com/blog/graphql-vs-or-rest/
https://devathon.com/blog/graphql-vs-or-rest/
Advantages of REST
The RESTful architecture emerged in 2000, and it offered a simpler way for a computer
to interact with another. This architecture utilizes the HTTP protocol for communication
between computers, and this communication is stateless, i.e., the server doesn’t store
any state about the client session on the server side.
Programmers working with someone else’s RESTful API doesn’t need to use any special
libraries, and they don’t need to implement any special initialization. When using RESTful
APIs, an application can send requests to another using common software like cURL and
web browsers.
REST uses HTTP data resources, i.e., URIs, and conventions, moreover, it uses CRUD
HTTP verbs like GET, PUT, POST, and DELETE. Developers using an API will need to
design their data model, however, they can use HTTP conventions to make their
programming easier. With REST, the data contracts are loose, while REST itself is
coupled tightly with HTTP.
https://devathon.com/blog/graphql-vs-or-rest/
https://devathon.com/blog/graphql-vs-or-rest/
Disadvantages of REST and why GraphQL emerged
While REST offered many advantages to developers and became the de facto standard
for businesses that deploy APIs, it also has a few disadvantages. These disadvantages
arise from the fact that the server creates the representation of the resource, and the
response to the client uses that.

We have seen a sharp increase in the usage of mobile devices since 2010. Some mobile-
devices were low-powered, moreover, the mobile networks were slow. Server-defined
representations of resources didn’t serve this scenario well.
These led to the search for an alternative to REST, and Facebook created GraphQL in
2012. GraphQL is a cross-platform data query and manipulation language for APIs. It’s a
runtime for executing queries against data, and Facebook open-sourced it in 2015. The
latest stable release of GraphQL was released in June 2018.

https://devathon.com/blog/graphql-vs-or-rest/
https://devathon.com/blog/graphql-vs-or-rest/
GraphQL vs REST: Similarities & Differences
Before we explain the similarities and differences between GraphQL vs REST, let’s
understand that GraphQL doesn’t necessarily have to replace REST. They can coexist in
one project. We analyze the similarities and differences between GraphQL vs REST
concerning the following aspects:

Resources
URL Routes
Route Handlers
Data Fetching

https://devathon.com/blog/graphql-vs-or-rest/
Similarities & Differences: Resources
The defining concept of REST is the resource, and it identifies resources as URLs. When
developers want to retrieve a resource in their application, they send an HTTP GET
request to the said URL. Since most APIs use JSON, developers will likely get JSON data
as the response.

Up to this point, GraphQL and REST are similar. GraphQL also has the concept of
resources, and it identifies them as URLs. Developers can send HTTP GET requests to
retrieve the resource, and they get JSON data as the response.

The other key different concerns with the shape and size of the resource, and in the
case of REST, the server determines it. When you use GraphQL, the server only tells you
what’s available. You write a query specifying what information you want to retrieve.

https://devathon.com/blog/graphql-vs-or-rest/
Similarities & Differences: URL routes
When a business designs APIs, it takes care to make the API predictable. This means
that developers using this API should know exactly what should they call, and what to
expect as response. API documentation standards stress upon this information being
very clearly presented so that the information can be easily used by application
programs.

Developers using GraphQL doesn’t use endpoints since they use the GraphQL schema.
A GraphQL schema has different initial types like “Query” and “Mutation”, and developers
specify their intended operation using these keywords.

Developers can use the same fields on the “Query” type as they would use in the
endpoints in case of REST. This is yet another similarity between REST and GraphQL.
However, GraphQL developers can then use complex GraphQL queries to access
additional data. These queries utilize the relationships defined in the GraphQL schema.
https://devathon.com/blog/graphql-vs-or-rest/
Similarities & Differences: Route Handlers
After developers call an API, there are pieces of code that execute on the server. These
pieces of code might compute something, call another API, load data from a database,
etc., REST and GraphQL have their own ways to implement this, and there are both
similarities and differences between them.

GraphQL resolvers allow processing multiple fields in one request, moreover,

developers can call the same field multiple times within a query. Using this flexibility,
programmers can create nested queries using these resolvers since they are attached to
various GraphQL types.

https://devathon.com/blog/graphql-vs-or-rest/
Similarities & Differences: Data Fetching
The differences between GraphQL vs REST we described above influence how the data
is fetched. A typical usage of REST API will fetch data by calling multiple API endpoints,
and the server will return all data in those endpoints.

As we have explained, GraphQL uses queries, schema, and resolvers. Developers can
specify the exact data they need, moreover, they can create and execute nested
queries. This difference in data fetching is a significant, as we will soon explain.

https://devathon.com/blog/graphql-vs-or-rest/
Why GraphQL over REST?
Resolution to over-fetching and under-fetching

As we have seen, apps using REST APIs call endpoints, and the entire data in that
endpoint will be returned in the JSON format. This results in over-fetching as well as
under-fetching.

In different ways, over-fetching and under-fetching can cause performance and

scalability issues. GraphQL with its queries, schemas, and resolvers enable developers to
design API calls that meet their specific data requirements. This way, GraphQL resolves
the over-fetching and under-fetching challenges.

https://devathon.com/blog/graphql-vs-or-rest/
Why GraphQL over REST?
Faster product iterations on the frontend

A common practice while designing REST APIs is to design the API endpoints according
to the views in the application. This helps the application to get the data required for a
view by simply accessing the API endpoint that corresponds to the view.

This requires changes to the API endpoints every time the frontend changes. Such
frequent changes to the backend impact the ability of the development team to change
the frontend, and this reduces the productivity.

GraphQL addresses this, thanks to its flexibility! Developers can write queries specifying
their data requirements, and the iterations for developing of the frontend can continue
without having to change the backend.

https://devathon.com/blog/graphql-vs-or-rest/
Why GraphQL over REST?
GraphQL enables better analytics on the backend

Applications that use REST APIs get the entire data in an API endpoint, as we have
explained. The application owner can’t gain insights on the usage of specific data
elements since the entire data is returned every time.

GraphQL, on the other hand, has queries, and developers use them to retrieve specific
data elements. It uses resolvers, and they implement particular fields in a type.
Application owners can track the performance of the system at the level of these
resolvers, and find out whether the system needs performance tuning. This granular
level of performance monitoring is an advantage of GraphQL over REST.

https://devathon.com/blog/graphql-vs-or-rest/
Conclusion
Both REST and GraphQL are prominent ways to design how an API will function and how
applications will access data from it. While REST had significantly simplified the work of
developers with its standardized approach, it does have a few drawbacks. GraphQL, with
its queries, schemas, and resolvers offer more flexibility, moreover, GraphQL can offer
better performance.

REST still holds on it own though, and you can use both REST and GraphQL in a project.
Carefully analyze your application, data, and performance requirements, so that you can
choose appropriately.

Are you looking for Mobile/Web app Development services? Contact us at

hello@devathon.com or visit our website Devathon to find out how we can breathe life
into your vision with beautiful designs, quality development, and continuous testing.
https://devathon.com/blog/graphql-vs-or-rest/