REST API vs GraphQL: Differences and When to Use Them

By 2026, global API traffic volume has surpassed figures that were hard to imagine a decade ago—several independent research institutions estimate that more than 85% of all internet traffic now flows through application programming interfaces. Recent reports from various API monitoring platforms show that monthly API calls in mid-to-large enterprises have grown by double digits on average each quarter, while the need for real-time, bandwidth-efficient user experiences has become increasingly urgent amid the surge in mobile and IoT devices. At this crossroads, software architects, CTOs, and developers are faced with a fundamental choice that will determine the scalability, performance, and operational costs of their digital products for years to come: stick with the mature and proven REST approach, or switch to GraphQL, which promises limitless flexibility. REST API and GraphQL are two primary paradigms for designing client-server communication interfaces—each with very different structural advantages, performance trade-offs, and adoption curves, and the decision between them should not be made dogmatically, but based on the actual needs of your project in an increasingly complex distributed architecture era.

What Are REST API and GraphQL? Two Ways to "Order Food" from the Server Kitchen

Imagine a modern restaurant. REST API works like a fixed menu that is neatly printed: each dish has a clear name, a predetermined portion, and a uniform ordering method. You order "Special Fried Rice" and the kitchen will send a full plate containing rice, egg, chicken, crackers, and pickles—regardless of whether you actually only wanted the rice. GraphQL, on the other hand, is a personal chef who accepts custom orders: "I want fried rice, but without pickles, the egg scrambled, and the chicken separated in a small bowl." The kitchen only prepares exactly what you asked for, no more and no less. This analogy reflects the most fundamental difference: REST determines the shape of the response from the server side, while GraphQL gives full control to the client to determine what data it needs.

Technically, REST (Representational State Transfer) is an architectural style that uses standard HTTP methods (GET, POST, PUT, PATCH, DELETE) to interact with resources identified through URLs. Each endpoint represents a single entity or collection of entities, for example /users/123 to retrieve data for one user or /orders for a list of orders. GraphQL, first introduced by Facebook (now Meta) and currently managed by the GraphQL Foundation, is a query language and execution runtime that allows clients to request data from multiple resources at once in a single request by explicitly defining the response structure through a schema.

In practice, these two paradigms give rise to several variants and usage patterns:

Pure REST (Level 0-3 Richardson Maturity Model): Ranging from the use of a single endpoint to full utilization of HATEOAS (Hypermedia as the Engine of Application State), where responses include links for navigating related resources.
REST with OpenAPI/Swagger: REST equipped with a machine-readable specification for automatic documentation, SDK generation, and API contract validation.
GraphQL Query and Mutation: Read operations (query) and write operations (mutation) that are explicitly defined in the schema, allowing clients to request specific fields across resources.
GraphQL Subscriptions: Real-time features based on WebSocket or Server-Sent Events that allow the server to push data updates directly to the client when changes occur.
GraphQL Federation: A microservices architecture pattern that breaks the GraphQL schema into multiple subgraphs managed by different teams but presented as a single unified API.
Hybrid/REST-GraphQL Bridge: Many organizations run both in parallel, using GraphQL as an aggregation layer on top of existing internal REST APIs.

Why API Architecture Choice Matters: Real Impact on Your Digital Product

1. Performance and Bandwidth Efficiency in the Mobile-First Era

Mobile devices now dominate internet access, and in many developing markets, users access applications through slow connections or expensive data plans. REST APIs with fixed response schemas often send excessive data (over-fetching) when the client only needs a small portion of the response, or force clients to make multiple separate calls (under-fetching) to collect data from various endpoints. GraphQL addresses both by allowing clients to request exactly the data they need in a single request, which can significantly reduce payload size and the number of network round-trips. In measurements across various migration projects, average payload size reduction ranged from 30 to 70 percent for common use cases such as product lists with seller details or social media feeds.

Case Study – Shopify: This global e-commerce platform made GraphQL its primary API for third-party applications and custom storefronts, because the need for merchants to retrieve product data, variants, prices, inventory, and reviews in a single request is very high—something that is difficult to do efficiently with pure REST without creating proliferating custom endpoints. As a result, Shopify app developers report a significant reduction in the number of API calls per user session.

2. Development Speed and Product Iteration

In modern product development cycles that demand rapid releases and continuous iteration, rigid API contracts can be the biggest bottleneck. Every change to client data requirements—for example, a mobile app wanting to display a new field in the user profile—often requires changes to the REST endpoint, documentation adjustments, and coordination between frontend and backend teams. GraphQL eliminates this bottleneck because the client simply adds a new field to its query without waiting for server-side changes as long as that field is already available in the schema. This dramatically accelerates the feature development cycle and reduces inter-team dependencies.

3. Architectural Scalability and Long-Term Evolution

As products grow and the number of clients increases—web, iOS, Android, third-party applications, IoT devices—the data needs of each client become increasingly diverse. REST APIs designed for one client often fail to meet the needs of other clients without creating new specific endpoints, which ultimately leads to endpoint proliferation that is difficult to manage. GraphQL, with its unified schema and strong type system, provides a more adaptive foundation for long-term product evolution. However, it is important to note that GraphQL scalability also brings its own challenges, especially in terms of caching and complex query optimization, which will be discussed in the challenges section.

4. Developer Experience and Tooling Ecosystem

The quality of tooling and documentation directly affects developer productivity. REST has very mature documentation through the OpenAPI standard, as well as universal support in almost all programming languages, frameworks, and cloud platforms. Meanwhile, GraphQL offers introspection features that allow IDEs and development tools such as GraphiQL or GraphQL Playground to automatically display the schema, validate queries in real-time, and provide autocomplete—an experience that many developers consider superior for API exploration. However, REST remains superior in terms of simplicity, ease of debugging with standard tools like cURL or Postman, and proven HTTP caching support.

REST API and GraphQL Adoption in Indonesia in 2026

Key Players: At the global level, the REST ecosystem continues to be strengthened by the OpenAPI standard, which has been widely adopted by cloud providers such as AWS, Google Cloud, and Microsoft Azure, as well as by popular frameworks like Express.js, Laravel, Spring Boot, and Django REST Framework. On the GraphQL side, major vendors include Apollo (with Apollo Server, Apollo Client, and Apollo Federation), Hasura (a GraphQL engine on top of PostgreSQL), Prisma (an ORM integrated with GraphQL), as well as native support from platforms like the GitHub GraphQL API, Shopify, and Contentful. The GraphQL Foundation under the Linux Foundation continues to coordinate specification development, supported by active contributors from Meta, AWS, Netflix, and many other major technology companies. In Indonesia, both the GraphQL and REST communities are equally active, with many technology startups beginning to adopt GraphQL for new products while maintaining REST for legacy integration or internal services that rarely change.

Local Success Stories:

Tokopedia uses GraphQL in several internal microservices and public APIs to allow frontend teams to flexibly compose product and transaction data, which helps accelerate the development of new features in their mobile and web applications.
Gojek (now GoTo) has implemented GraphQL as an aggregation layer on top of many internal REST microservices, allowing their super-app to retrieve data from various domains—transportation, food delivery, payments—in a single request, reducing latency on Indonesia's diverse mobile networks.
Bukalapak utilizes GraphQL for several public endpoints serving partners and sellers, enabling easier integration for third-party developers who need specific data without over-fetching.
Several digital banks and fintech companies in Indonesia are also starting to explore GraphQL for their internal APIs, especially for analytics dashboards and customer data aggregation services, while continuing to use REST for payment APIs that require strict security and audit standards.

Challenges & How to Overcome Them

1. GraphQL Caching and Query Optimization Complexity

One of the main advantages of REST is its ability to leverage standard HTTP caching mechanisms such as ETag, Cache-Control, and CDN edge caching simply and effectively. GraphQL, because it uses a single endpoint and POST requests for most operations, cannot directly utilize traditional HTTP caching, requiring special caching strategies such as persisted queries, DataLoader to avoid the N+1 problem, and application-layer caching with Redis or Apollo Server Cache. The way to overcome this is to implement persisted queries that provide a unique ID for each registered query, allowing the server and CDN to cache safely, and use DataLoader to batch and deduplicate requests to the database.

2. Security Risks and Query Abuse

The flexibility of GraphQL that allows clients to request data freely also opens the door for very deep or very wide queries that can disproportionately burden the server. Without safeguards, a client can send a nested query that triggers thousands of database resolutions in a single request. Solutions include implementing query depth limits, query complexity limits based on a scoring system for each field, strict rate limiting, and execution timeouts. In addition, authorization must be applied at the resolver level (field-level authorization), not just at the endpoint level as in REST, because each data field in the GraphQL schema can have different permission requirements.

3. Learning Curve and Specialized Skill Requirements

Although GraphQL offers many advantages, development teams accustomed to REST patterns will face a learning curve, especially in understanding schema concepts, resolvers, and good GraphQL architecture patterns. In addition, debugging complex GraphQL queries requires special tools and a deep understanding of how the GraphQL runtime works. The way to overcome this is to conduct team training gradually, start with small-scale internal projects before implementing GraphQL on public APIs, and adopt proven architecture patterns such as GraphQL Federation to break down complexity at scale.

4. Infrastructure Overhead and Operational Costs

GraphQL with its centralized schema can become a bottleneck and single point of failure if not designed properly, especially in distributed microservices architectures. Every GraphQL request can trigger many internal calls to different services, adding latency and operational complexity. The solution is to implement GraphQL Federation, which allows each team to manage their subgraphs independently, use a gateway that handles routing and aggregation, and adopt an event-driven architecture for real-time use cases through subscriptions.

The Future of REST API vs GraphQL

GraphQL as a Standard Aggregation Layer: The trend in 2026 shows that more and more organizations are adopting GraphQL not as a total replacement for REST, but as an aggregation layer on top of existing internal REST APIs, creating a hybrid architecture that leverages the strengths of both.
Increased Adoption of GraphQL Subscriptions for Real-Time: With the growth of collaborative applications, live dashboards, and real-time notifications, the use of GraphQL subscriptions is expected to continue increasing, especially supported by the transition to more efficient WebSocket and Server-Sent Events.
Standardization and Interoperability: The GraphQL Foundation's efforts to expand the specification—including better HTTP caching support and standards for GraphQL over HTTP—will drive broader adoption by reducing existing technical barriers.
REST Remains Relevant for Specific Use Cases: For simple public APIs, legacy integration, machine-to-machine communication that rarely changes, and services that require maximum HTTP caching, REST will remain the primary choice due to its unmatched simplicity, maturity, and universal support.

Conclusion: Choosing the Right Architecture for Your Needs in 2026

REST API and GraphQL are not bitter enemies that cancel each other out, but rather two tools with different strengths that can complement each other in the modern architectural landscape. REST excels in simplicity, efficient HTTP caching, universal support, and its suitability for stable, rarely changing public APIs. GraphQL offers remarkable flexibility, reduction of over-fetching and under-fetching, and a superior developer experience for applications with complex and dynamic data requirements. The decision between the two should be based on the specific characteristics of your project: data complexity, client diversity, real-time needs, team maturity, and long-term strategy. In 2026, the wisest approach for many organizations is a hybrid architecture—using REST for simple and stable use cases, while adopting GraphQL as an aggregation layer for applications that require high flexibility. By understanding the fundamental differences and trade-offs of both, you can make architectural decisions that not only meet current needs but also build a solid foundation for the scale and evolution of your digital products in the future.