REST has been a de facto architectural style for designing APIs (Application Programming Interfaces). However, since the advent of GraphQL, REST’s reign in the API world has been threatened.
There is a raging debate on GraphQL vs. REST, and most enterprises are at crossroads on which one to go with when creating or consuming APIs. While REST is popularly regarded as the standard way to design APIs, GraphQL is increasingly touted as a revolutionary technology capable of trumping REST’s weaknesses.
In this article, we’ll make a detailed comparison between REST and GraphQL so that you can choose the one that best suits your needs.
Table of Contents
Let’s dive in!
A brief history of APIs
As we know them today, APIs first appeared in the early 2000s from big corporations like Salesforce and eBay. These APIs largely relied on SOAP (Simple Object Access Protocol) to allow for the structured exchange of web data using the XML (extensible markup language) format. The notable precursors to SOAP were CORBA and RPC.
While SOAP offers useful features for utilizing APIs, such as built-in error handling that allows for quick fixing of problems, it also has some downsides. Primarily, it is complex to call, supports only a single data format, and requires a large bandwidth.
Therefore, when the REST architectural principle was introduced in 2000, developers quickly fell in love with it. REST simplifies machine to machine communication and supports a wide range of data formats, such as JSON, XML, and YAML. Although it has been extensively adopted, REST still has some shortfalls.
The need for a newer, even easier architectural style led Facebook to develop GraphQL in 2012. It was released to the public in 2015. While GraphQL has not yet reached the realms of REST, many API consumers cheer it as the REST killer, or “REST in peace.”
This is what has led to the head-to-head REST vs. GraphQL debate.
Basics of a REST API
The REST (short for representational state transfer) design paradigm centers on a uniform and predefined set of stateless operations that enable users to access and manipulate web data. APIs that conform to REST design principles are usually called RESTful APIs.
In REST architecture, APIs expose their functionality as resources, which are any type of service, data, or object that a client can access. Every resource comes with its own unique URI (Uniform Resource Identifier) that a client can access by sending a request to the server.
So, whenever a client calls a RESTful API, the server will respond with a representation of the state of the queried resource. Many common REST implementations utilize the standard HTTP methods (GET, POST, PUT, DELETE, and PATCH) to call a server.
Basics of a GraphQL API
GraphQL is a query language for working with APIs. The language enables the client to make HTTP requests and get responses.
In GraphQL, a set of information is seen in the context of a graph, just as the name suggests. Nodes, which are defined using the GraphQL schema system, represent objects. And edges represent the connection between nodes in the graph. This enables clear relationships between queries and increases the connectivity between objects.
GraphQL allows users to request data from several resources using a single request. Rather than making multiple requests to fetch data, you can use it to make ad-hoc queries to a single endpoint and access all the required data.
Furthermore, GraphQL provides the client with the luxury to specify the exact type of data to be received from the server. Nothing more, nothing less. This predictable data structure makes it highly readable and efficient.
REST and GraphQL comparison
GraphQL versus REST. That has been an intense debate in the API world for a while now. And frankly, they are just two different methods for solving the same problem: accessing data from web services.
While the two technologies have some similarities, subtle differences may make you opt for one over the other.
So, to help you make the right decision on which one to go with, we’ll evaluate them based on the following key factors:
- Popularity
- Usability
- Performance
- Security
Let’s talk about each of the factors.
1. Popularity
Most popular open source technologies have been community-tested and are likely to be mature and stable. Furthermore, adopting a widely popular technology can help you leverage community support if you experience any issues during implementation.
When it comes to GraphQL vs. REST popularity, the latter is clearly ahead. The former is the new kid in the block trying to catch up with an already established API design style.
For example, according to the recently released State of API 2020 Report, 82% of the surveyed API practitioners and consumers use the REST-based OpenAPI specification, while only 19% use GraphQL.
Nonetheless, GraphQL’s popularity is proliferating. According to the State of JavaScript 2019 report, while only 5% of the surveyed developers had used it in 2016, 38.7% used it in 2019.
Notably, the rising GraphQL popularity has inspired the creation of other query languages with GraphQL-like syntax. For example, RapidQL is an open source language that is a customized spin-off of GraphQL. It provides a simplified and reliable way of querying multiple data sources, such as APIs.
While GraphQL’s usage is increasing rapidly, it’s still somewhat new and may need more time to reach the realms of REST.
So, do you think GraphQL may overtake REST’s popularity in the next few years? Is GraphQL the future? Or, will GraphQL replace REST?
Please share your thoughts in the comment section below.
2. Usability
When it comes to REST API vs. GraphQL API usability, the two are completely different beasts, especially in terms of predictability and versioning.
One of the strongest GraphQL’s appeals is its high predictability. GraphQL allows you to send a request to your API and get the exact results you require—without unnecessary inclusions. Its queries return predictable results, which highly increases its usability.
On the contrary, REST’s behavior usually varies based on the URI and HTTP method used. This makes it unclear for an API consumer to know what to expect when calling a new endpoint.
In terms of versioning, REST lacks clear and standardized guidelines for versioning. This implies that every provider is free to implement their own approach. In fact, REST’s creator, Roy Fielding, believes that APIs should not be versioned—something that the REST community has been going against. Are you one of them?
Nevertheless, in recent years, there has been increased adoption of the OpenAPI Specification format, which provides standardized ways to describe and version REST APIs. We are likely to see most RESTful APIs using this standardized API documentation and versioning format in the near future.
On the other hand, GraphQL follows a clear and straightforward approach to versioning: do not version APIs. Period.
So, if we compare GraphQL vs. REST API in terms of predictability and versioning, GraphQL’s simplicity significantly adds to its usability. According to a recent study, GraphQL, when compared to REST, needs less effort to integrate remote service queries.
Conversely, REST’s great flexibility is a neutral feature, which may impact usability either negatively or positively based on a person’s preferred API design technique.
3. Performance
Performance is another hotly debated issue in the GraphQL versus REST contest. RESTful services are often discredited because of being prone to under-fetching and over-fetching.
Over-fetching occurs when an endpoint returns superfluous data than is actually required. Conversely, under-fetching implies that an endpoint cannot return a sufficient amount of the required data.
Since REST APIs inherently have rigid data structures designed to return the stipulated data whenever they get hit, you may get unnecessary data or be forced to make multiple calls before getting the relevant data. These inadequacies also escalate the time it takes for the server to return all the requested information.
On the contrary, GraphQL, rather than using fixed server-defined endpoints, uses a flexible style that allows you to retrieve what you want in a single API request. After defining the structure of the information you need, the same structure will be returned to you from the server, which avoids under-fetching and over-fetching.
Whereas the GraphQL vs. REST performance debate may seem to favor the former, there are some development instances where RESTful APIs are a better option. For example, in cases where caching is desired to expedite API calls, REST APIs can perform better.
REST APIs leverage the built-in HTTP caching mechanism to return cached responses faster. While GraphQL has to get back to the source to fetch the required data, REST can quickly retrieve it from the browser or mobile cache. Indeed, GraphQL also has some options for caching, but they have not reached REST’s level.
So, in a GraphQL vs. REST performance benchmark analysis, a winner may not be clear-cut. Though GraphQL simplifies the number of requests an average application requires, REST tops it in the robustness of caching capabilities.
4. Security
In terms of GraphQL vs. REST security, the credit seems to be leaning towards the latter’s side. REST provides several inherent ways to enforce the security of your APIs.
For example, you can ensure REST API security by implementing different API authentication methods, such as via HTTP authentication, where sensitive data is sent in HTTP headers, via JSON Web Tokens (JWT), where sensitive data is sent as JSON data structures, or via standard OAUth 2.0 mechanisms.
While GraphQL also provides some measures to ensure your APIs’ security, they are not as mature as those of REST. For example, although GraphQL assists in integrating data validation, users are left on their own to apply authentication and authorization measures on top. This often leads to unpredictable authorization checks, which may jeopardize the security of GraphQL-based apps.
Furthermore, a demonstration analysis found out that GraphQL complicates implementing rate-limiting and other denial-of-service protective measures, lacks proper validation for self-defined or custom scalar data types, and its introspection function can expose sensitive internal data models.
GraphQL vs. REST pros and cons
Let’s now talk about the main advantages and disadvantages of the two API design techniques.
Here are the pros of REST:
- Mature and proven for decades
- Handles various types of calls and supports various data formats, including plain text, HTML, and JSON
- Decoupling of client and server architectures provides great scalability for expanding applications easily
Here are the cons of REST:
- Prone to under-fetching or over-fetching of data
- Multiple round trips of requests required to fetch all the data needed
- No specific, standardized methodology of structuring REST APIs
Here are the pros of GraphQL:
- The presence of a strong type system, which is expressed as a schema, dramatically reduces the effort required to implement queries. The type system stipulates the data structure the server can return
- Suitable for avoiding under-fetching or over-fetching of data
- Suitable for parallel API development for both front end and back end
Here are the cons of GraphQL:
- Lacks built-in caching capabilities
- Since it always returns an HTTP status code of 200, whether the request is successful or not, this may complicate error reporting and API monitoring
- Lacks extensive adoption and support
REST and GraphQL differences
Are you wondering about what is the difference between REST API and GraphQL?
Here is a table that showcases their main differences:
| GraphQL | REST |
| A query language offering efficiency and flexibility for solving common problems when integrating APIs | An architectural style largely viewed as a conventional standard for designing APIs |
| Deployed over HTTP using a single endpoint that provides the full capabilities of the exposed service | Deployed over a set of URLs where each of them exposes a single resource |
| Uses a client-driven architecture | Uses a server-driven architecture |
| Lacks automatic caching mechanism | Uses caching automatically |
| No API versioning | Supports multiple API versions |
| JSON representation only | Supports multiple data formats |
| Only a single tool is used predominantly for documentation: GraphiQL | Wide range of options for automated documentation, such as OpenAPI and API Blueprint |
| Complicates handling of HTTP status codes to identify errors | Uses HTTP status codes to identify errors easily |
GraphQL vs. REST, which is better?
The answer to the question above is extremely subjective and largely depends on your specific project requirements.
For example, if you want to breathe some fresh air into your API development using a modern design style that does not require making multiple round trips to fetch data, then GraphQL could be your best option.
On the other hand, if you intend to use a tried-and-proven technique that comes with robust native caching or authentication capabilities, then REST could be your best option.
If you know the constraints and tradeoffs that go into each API design style, you can comfortably pick the option that best fits your use case. Better still, you can employ a mix-and-match approach that uses both of them.
Ultimately, regardless of your choice, you should aim to design an API product that meets the needs of all the participants in the API value chain: the API provider, the API consumer (developer), and the end-user (customer).
Using Rakuten RapidAPI Enterprise Hub
Rakuten RapidAPI Enterprise Hub is a centralized API platform that allows you to make the most of your internal APIs as well as external API subscriptions, whether you pick GraphQL or REST for your web service.
The Enterprise Hub comes with a full suite of tools for enforcing the security, discoverability, and governance of your APIs. With the Hub, you can get rid of the day-to-day administrative hurdles of managing your API programs, ensuring you realize their full value.
If your enterprise wants a powerful and customized portal for your REST or GraphQL APIs, send us an inquiry right now.
Leave a Reply