REST Still Outshines GraphQL for Many API Use Cases

Over the past several years, I kept hearing that GraphQL — a query language for APIs that lets clients request specific data — is the future of APIs. Its hype comes from clear and compelling value props. Namely, it can help you get the exact data you need and access multiple resources from a single request, saving you time, money, and bandwidth.

But as you begin using GraphQL, you’ll find that it creates an entirely new set of issues that overwhelm its benefits.

I’ll break down these issues so that you can better decide whether GraphQL is worth using across your integrations. I’ll also highlight why REST is a better alternative today and will continue to be the leading API standard.

The Drawbacks of GraphQL

I can point to several fundamental issues with using GraphQL. For starters, GraphQL often leads to complex queries that seriously strain backend performance. This can translate to long processing times, negating one of the promised benefits of GraphQL — a faster response time. Deeply nested queries can even cause servers to go down, further delaying responses.

In addition, GraphQL typically applies rate limiting based on the complexity of a request — such as the number of fields or objects being requested. As you increase the resources in your requests over time, understanding and following your rate limits will become more complex.

Finally, as an API matures, its GraphQL schema becomes more complex. Successfully navigating this growing complexity is not only painful from a rate-limiting perspective but can also lead to costly mistakes when your team structures requests.

Why REST Is Better and Here to Stay

Here are a few reasons why REST is the best option for integrating SaaS applications.

1. REST APIs come with standardized error codes.

These codes — which include everything from a 404 (Not Found) to a 500 (Internal Server Error) — make it easy to diagnose issues and build error-handling flows that address them automatically. For example, if you get a 429 Too Many Requests error, you can create an automated retry based on the suggested wait time in the response.

GraphQL, on the other hand, requires your engineers to account for the response provided in the errors key. And since these responses aren’t as standardized as in REST, they’re harder to plan for and handle automatically.

2. Many engineers have experience building and/or maintaining REST API integrations.

Companies of all shapes and sizes primarily use REST APIs.

Case in point: According to research from Gartner, REST APIs are used by 85% of organizations — while GraphQL is only used by 19%.

Given REST’s popularity, your developers are likely experienced and comfortable with building and maintaining REST API integrations. It’s also less effort to find and hire engineering talent with experience working with REST, making it easier for your organization to scale REST API integrations over time.

In addition, while API providers will inevitably struggle to get developers to integrate with them, offering APIs in the architecture that developers are most familiar with will remove a significant barrier to adoption.

3. REST’s open source ecosystem is significantly more comprehensive than GraphQL’s.

A wide range of backend frameworks and libraries for REST can auto-generate OpenAPI specifications. These tools are also available in several programming languages, allowing your developers to work in the language they’re most comfortable with.

Beyond OpenAPI, you can access diverse open source tools to manage every facet of REST API development, including validation, security, monitoring, and testing.

Postman is well suited to test REST APIs; OpenAPI lets you auto-generate API documentation;  REST frameworks (e.g., Django REST Framework) are built for specific programming languages and provide tools that help you build APIs efficiently, etc.

This isn’t to say that tooling doesn’t exist for GraphQL; there are simply more REST-related extensions that are better supported.

Final Thoughts

As the API space continues to mature, I suspect that additional API architectures will be released and receive similar hype to GraphQL. This hype will mostly come from those who have yet to leverage them in meaningful ways, if at all.

Until a competing API architecture can exceed — let alone match — REST’s utility for both providers and consumers, REST will continue to be the preferred choice.