APIs and REST are often thought of together, to the point of being synonymous or used interchangeably. This is largely due to Roy Fielding’s dissertation, where he laid out the conditions that would become REST, which is like the Declaration of Sentiments for APIs.

Representational state transfer is still a helpful design style to consider, but many things have changed since Fielding first defended his dissertation in 2000. Many more API frameworks have emerged in the last two decades, some of which take advantage of more recent technological innovations. GraphQL is one of the more popular modern frameworks due to its efficiency and ability to be customized.

Below, we’re going to look at GraphQL and how it stacks up against REST with a detailed REST vs. GraphQL side-by-side comparison. Before we dive in fully, let’s look at both REST and GraphQL individually to help give you some context to understand their similarities and differences.

What Is REST?

REST stands for REpresentational State Transfer. It’s intended as a standard so users can work with data over the web even with little external context.

REST exposes data, which are known as resources, usually to an endpoint. This also lets you perform rudimentary actions on the data via the API itself. The most common REST commands are GET, POST, PUSH, and DELETE. These are performed using standard HTTP methods.

What Is GraphQL?

Comparing GraphQL and REST is like comparing apples and oranges. For one thing, REST is as much a philosophy and way of thinking. GraphQL, on the other hand, isn’t even an API specification. GraphQL is a query language for working with APIs.

Unlike REST, GraphQL is optimized for working with relational databases. GraphQL is organized around Nodes, known as objects. This creates clear corollaries between queries and objects, which is useful for a number of applications in today’s data-rich world.

GraphQL’s other main distinction is the ability to access multiple data entries with a single query. This makes GraphQL more efficient for many applications as it involves fewer API calls. This is particularly significant as mobile technology wasn’t as prevalent when Fielding defined REST back in 2000.

REST vs. GraphQL: A Side-By-Side Comparison

Now let’s take a look at both REST and GraphQL using various criteria to help give you an idea of the similarities and differences. Knowing this could help determine which framework to use in your development projects.

REST vs. GraphQL: Popularity

Seeing as how REST was created back in 2000, while Facebook developed GraphQL and open-sourced it in 2015, there is some familiarity bias regarding REST. According to last year’s State Of API Report, 82% of companies using APIs are using REST, while only 19% use GraphQL.

Even as the new kid on the block, GraphQL has some impressive advocates. Huge companies like Airbnb, Coursera, DailyMotion, GitHub, and, of course, Facebook are all using GraphQL. This alone speaks to the query language’s usefulness and potential.

GraphQL’s popularity is clearly on the rise, as well. According to the 2019 State Of JavaScript Report, 38.7% of companies surveyed were using GraphQL in 2019, while only 5% had adopted the query language in 2018.

REST vs. GraphQL: Popularity Summary

• With REST being virtually synonymous with APIs, REST is far more widely used than GraphQL.
• GraphQL is quickly closing the gap, though. Adoption increased from 5% to 38.7% in a single year.

REST vs. GraphQL: Usability

One of the strongest things GraphQL has going for it is its specificity. Thanks to GraphQL’s ability to send custom queries, it’s easy to obtain the exact data you need from your database. These results are returned in an entirely predictable format which allows for easy API consumption.

REST results are much more difficult to predict, though. A REST query will simply return all of the data from a particular resource. This can sometimes result in prohibitively large data dumps, which can have disastrous results in circumstances where you have to pay for usage like mobile data plans.

REST lacks clear guidelines on versioning, another drawback. Roy Fielding felt that APIs should never be versioned, so he failed to create specifications on how developers should implement it. Zero versioning is challenging to achieve in reality, and a lack of versioning uniformity makes consuming REST APIs even more complicated.

GraphQL’s predictability makes it easier for API consumers to adopt GraphQL without having to worry. This ease of use is one of GraphQL’s strongest selling points.

REST vs. GraphQL: Usability Summary

• Thanks to its extensive customizability, GraphQL is slightly easier to use than REST.
• GraphQL is more predictable when it comes to data usage. It lets you specify exactly what data to retrieve, eliminating the potential for massive data dumps as you might sometimes get with REST.

REST vs. GraphQL: Performance

Performance is one area where GraphQL has a fairly clear advantage over REST. REST is notorious for over- and under-fetching data, leading to unnecessary API calls and the risk of outmoded data.

These inefficiencies also add to processing time, meaning that apps using GraphQL often perform significantly faster than apps relying on REST.

This is not to say that GraphQL doesn’t have its downsides, though. GraphQL notoriously under-performs when it comes to caching. HTTP has a built-in cache function, which returns cached results far more quickly than GraphQL, which in its native form has to make a new call every time.

In this case, GraphQL’s greatest strength is also its weakness. GraphQL’s single endpoint for queries can serve as a bottleneck, greatly diminishing performance in several scenarios.

REST vs. GraphQL: Performance Summary

• GraphQL’s customized queries enhance performance in various ways, from reducing the number of necessary API calls to ensuring you get the right amount of data.
• GraphQL’s single endpoint can become a bottleneck in some circumstances.
• REST has an advantage for applications that require caching.

REST vs. GraphQL: Hypermedia

According to Fielding, an API must conform to hypermedia constraints to qualify as REST. This means the API returns a response body containing links to further resources to navigate the API. This is important, as it meets the restrictions that an API should be as self-contained as possible. The API consumer doesn’t need to know the URL for every API asset before runtime to use the API since the hyperlinks make it navigable.

GraphQL features no such constraints. Many of the same results are achieved using GraphQL schemas, but there are still some limitations and murky gray areas. This is a large stumbling block towards GraphQL being completely self-contained.

Luckily, there are workarounds if you’re solely using GraphQL. You can include fields that specify what actions are allowed, what file types are supported, and even a section for links.

REST vs. GraphQL: Hypermedia Summary

• REST is the clear winner when it comes to dealing with hypertext/hypermedia. This makes REST APIs far more self-contained.
• If you ARE intent on using GraphQL, you can include assets that work almost like hypermedia.

REST vs. GraphQL: Security

When it comes to API security, REST has a slight advantage.

Thanks to its popularity and wide adoption, there are a ton of authentication methods to ensure security. The variety of methods also makes it easy to implement different levels of permissions. You might use HTTP headers for sensitive data, using either Java Web Tokens or OAuth 2.0 authentication methods.

GraphQL users are left to their own devices when it comes to security. GraphQL does have some native functions for data integration, but the end-user needs to supply their own authentication and authorization methods over the results. This can lead to some vulnerability in GraphQL apps.

REST vs. GraphQL: Security Summary

• When it comes to security, REST has the advantage.
• REST’s widespread adoption means there are a ton of authentication and authorization resources available.
• It’s also easy to implement permissions in REST using a variety of request and authorization types.

REST vs. GraphQL: Conclusions

At the end of the day, the REST vs. GraphQL question will mostly boil down to taste. Many applications benefit from custom queries and the ability to sculpt results in any way you want, like you can with GraphQL. Its laser focus ensures you get exactly and only what you need.

REST still has plenty going for it, though. Thanks to its reputation and popularity, there are tons of tools, resources, and frameworks for working with REST. REST’s API security is another strong selling point.

As a good rule of thumb, if you’re working on a project where heavy data usage matters, GraphQL is a good choice. You’re much less likely to get data dumps or have to make unnecessary API calls when you use GraphQL.

GraphQL is a good choice for when you need consistent, uniform data, as well. It’s effortless to plug GraphQL into an app and have it work instantly. Thanks to inconsistencies in API specifications like you can sometimes find with REST, you sometimes have to wrangle the data or do some external research to achieve data compliance.

If you’re building an app or digital project where caching is important, however, REST would be a better bit thanks to the in-built HTTP caching capabilities.

Either way, both formats have a lot of strong points to recommend their usage. If you’re new to either, try experimenting with them both to see how each fits into your development workflow.