Comparing REST vs. GraphQL

In our API-heavy, data-driven world, applications are front and center when it comes to delivering exceptional user experiences. How services communicate fundamentally impacts how users request information throughout their active sessions. Accordingly, REST and GraphQL have grown to become leading technologies for developers. Each plays a critical supporting role in feature enablement—connecting the user’s frontend interactions with backend mechanisms.

REST is undoubtedly the more mature member of the duo. Introduced in 2000 by Roy Fielding, Representational State Transfer (REST) was created to facilitate seamless machine-to-machine communication. Preceding protocols like SOAP and RPC were decidedly restrictive due to their client library dependencies. Plenty of legwork was needed to effectively translate API payloads into something usable. Thankfully, REST architecture alleviated these concerns by working via HTTP—an internet protocol that still enjoys massive popularity today. REST APIs have since become the de facto standards across the industry.

Twelve years later, Facebook would introduce the world to GraphQL after a lengthy internal development period. Seeing its first public action within Facebook’s iOS app that year, the query language was later open sourced in 2015. Note that we say “query language” instead of “architecture” here. Opposite to REST, GraphQL occupies an interesting niche in the software realm because its structure is so fundamentally different (but more on that later). Facebook engineers developed GraphQL to solve a very tricky problem: requesting complex, nested data while maintaining performance. Overall, GraphQL has been long focused on returning control to the client.

Both REST and GraphQL certainly have their devotees. How exactly do they compare? Follow along as we analyze both technologies from a variety of perspectives.

What is REST?

REST is an API architecture first and foremost. We describe it as such because REST APIs follow a very specific blueprint, and these resource arrangements determine how applications request data. REST APIs know how to locate a vast array of information thanks to their underlying URI structure. These Unique Resource Identifiers can recognize (and ultimately help serve) a number of items to users. These might include the following:

• Electronic files and documents
• Images
• Webpages

REST is based on standard CRUD verbiage to interact with resources, including GET, POST, PUT, and DELETE. Any REST API can read, create, update, and remove resources, respectively. RESTful architectures also leverage a server to route requests. This server is an intermediary between clients and resources, which provides authentication, authorization, and therefore some degree of isolation between users and data. These APIs are also stateless; requests and their responses are independent from others.

REST excels at retrieving a boatload of data without impacting server performance at scale. Its interfaces are uniform—making it ideal for working across different tech stacks—and simplifies client-server communication. This flexibility is an awesome asset to software engineers. Just one API can provide value to numerous customers.

There’s also been a strong push to standardize REST API design. The OpenAPI Initiative and OpenAPI Specification (OAS) are community-driven efforts to promote agnosticism across APIs. The goal is designing REST APIs in program-agnostic ways, thus making it that much easier to integrate them within existing products or services. Additionally, the OAS provides ample documentation to ease this transition.

What is GraphQL?

GraphQL is a query language, and is therefore structured quite a bit differently than REST. The language uses schemas as opposed to URIs when describing resources. Schemas provide context to the data that clients might request via GraphQL API. These schemas also define queries. They’re central to outlining overall data requirements.

Fields and strings are therefore central to GraphQL’s API structure. Queries are instructions given from the client to the server—essentially telling the server to grab a specific piece of information. Accordingly, node queries are used to reveal objects specific to certain IDs. GraphQL is also stateless like REST.

GraphQL is useful within very data-rich applications that rely upon multiple databases. GraphQL is quite efficient at grabbing data from, and connecting, these sources of information to make complex requests. Despite this, GraphQL API requests are incredibly streamlined. The language is also flexible and not beholden to many design standards. Developers have some added leeway when crafting their APIs—for better or worse.

Today, GraphQL is heavily used by a number of large tech companies. Facebook, Airbnb, PayPal, Netflix, Shopify, and others use GraphQL to boost development agility. The scalability of GraphQL services is another draw.

While it’s true that GraphQL isn’t subject to sweeping standardization efforts, there are some best practices to consider. Nullability, pagination, and versioning are some important aspects to keep in mind while creating your API.

Comparing Efficiency and Performance

Overall, GraphQL and REST follow very different data-retrieval philosophies. REST tends to be a little more heavy-handed, in that one request can return payloads containing extraneous data. This is potentially useful for providing context, but is unfortunately extra demanding from a performance standpoint. The network has to handle larger payloads on average. Conversely, GraphQL was created with specificity in mind. Queries tell the server to only return certain pieces of information—minus the bloat. REST APIs are prone to this problematic overfetching.

What about server round-trips? GraphQL wins here, because a user can query multiple data sources simultaneously using one complex request. That means less stress on the network and decreased load on the server. Meanwhile, a REST API would need to make separate requests to each of these databases, thus consuming more resources to achieve the same outcome.

Getting a GraphQL server integrated and running is pretty easy thanks to its agnostic nature. The APIs mesh well with existing backends, and don’t require rewrites to function properly. Developers spend minimal time on integration. Accordingly, the libraries for different backend languages (C#, Node, etc.) are readily available. REST was also designed with similar priorities in mind.

REST’s design is more complex because one API leverages multiple endpoints. This does increase the scope of the backend to some degree, especially compared to GraphQL—which uses one unified endpoint for all queries. This consolidated approach is convenient but can act as a bottleneck in some high-volume scenarios.

What about response time? [An MDPI study]( revealed that REST wins here pretty handily, with a caveat. The average REST response time was 922.85ms, while GraphQL clocked in at 1864.50ms. However, a typical REST API is more resource intensive overall than its GraphQL counterpart—especially in memory and compute. Why is REST so fast? Caching plays a massive role. This is lacking natively in GraphQL (though could come later on), but developers can somewhat overcome this challenge via batching.

Comparing Usability

Generally, the specificity of GraphQL boosts usability because the API’s results are so predictable. This isn’t quite the case with REST, though, and large data dumps can be taxing for mobile data users. This is where REST can impact the client, and why Facebook was so keen to adopt GraphQL. However, both API structures have their own components—like schemas, URIs, and URLs—required to achieve resource access.

GraphQL queries and schemas are highly customizable. This allows developers to design their APIs more creatively, or in a fashion better suited to unique use cases. REST’s relatively-rigid design requirements require a little more work to “fit in.”

Thankfully, documentation is pretty accessible for both technologies. REST has been around for quite some time, and with help from the OAS, there are ample reference materials. There are also mechanisms for automatic documentation. Likewise, GraphQL is open source and well-maintained—though the language is still fairly new. GraphQL is also self-documenting. While REST is more mature, GraphQL is still evolving and may incorporate missing features in due time.

Both technologies also present responses to the user in unique ways. REST responses are in JSON format, and the body may contain file paths, buffer contents, and success or failure alerts. The response header contains info on anything from the server, to the date, to a description. Meanwhile, all GraphQL API responses are also in JSON. They contain keys for data, errors, and extensions.

Comparing Security

When it comes to security, REST is a clear winner for the time being. The architecture bundles together native mechanisms for authentication and authorization, giving it a clear leg up. For example, REST API developers can incorporate web tokens or OAuth 2.0. It’s also easy to setup permissions.

GraphQL unfortunately offers fewer built-in options. It’s lesser popularity means that fewer security measures have been developed. Developers must supply authentication and authorization themselves. This manual integration—or the absence of these at all—can create vulnerabilities in some GraphQL applications.

Comparing Hypermedia

Lastly, hypermedia is another divider between REST and GraphQL. REST was designed with hypermedia in mind; its APIs’ response bodies contain links to other resources, which help users navigate them. Consumers can get around without extensive knowledge of numerous URLs. This offers yet another usability boost as well. The creator of REST even stipulates that hypermedia support is mandatory for REST APIs. Because of this, these APIs are considered more self-contained.

Conversely, GraphQL schemas can help replicate this functionality, though there’s no hypermedia standard. Support isn’t required. The onus is on the developer to determine the extent of their API’s hypermedia inclusiveness, though more work is involved. Thankfully, GraphQL lovers aren’t left high and dry. Schema fields can specify permitted actions, type support, and even create a links section.

Hypermedia and hypertext support isn’t as fleshed out in GraphQL. How that support evolves remains to be seen, though the fundamental foundations of GraphQL might make that more challenging.

Conclusion

As with most comparisons, there aren’t always clear winners and losers. The viability of REST and GraphQL will depend on your application use cases and goals. Additionally, REST has an advantage. Having been introduced 12 years earlier, the API architecture has had ample opportunities to become functionally robust. GraphQL is still in its infancy by comparison.

Thankfully, neither technology is inherently “bad” at doing one specific thing—rather, REST and GraphQL slightly outshine each other in different areas. No matter which you choose, you’ll enjoy good documentation and can draw knowledge from enthusiastic communities.

REST is well-entrenched and that doesn’t seem to be in jeopardy. GraphQL is also on the rise. Just three years ago, 37.8% of companies were using it (vs. only 5% in 2018), and interest has only grown since. Without doubt, both will be powering modern applications as we wade deeper into the microservices space.