When teams sit down to design a new API, the REST vs GraphQL question comes up almost immediately. Both approaches let clients talk to servers, fetch data, and trigger actions. But the philosophy behind each is different enough that picking the wrong one can create real friction as a product scales. Understanding the trade-offs is not just useful for architects; it matters to every developer who will live with the choice.
What REST actually is (and what it is not)
REST (Representational State Transfer) is an architectural style, not a protocol. It uses standard HTTP methods, GET, POST, PUT, PATCH, and DELETE, mapped to resources exposed as URLs. A /users/42 endpoint returns a user; a DELETE /orders/7 removes an order. The pattern is predictable, stateless, and well understood by every HTTP client that exists.
The appeal of REST is its simplicity and its alignment with the web itself. Browser caching, CDN edge caching, and HTTP intermediaries all work naturally with REST because they understand the semantics of HTTP verbs and status codes. REST APIs also tend to be straightforward to document, easy to version (via URL path or Accept header), and simple to test with nothing more than curl or a browser.
The limitations show up as products mature. A mobile client that needs to display a user's name, their last three orders, and the status of a pending delivery might have to call three separate endpoints. This over-fetching (getting far more data than needed) and under-fetching (needing multiple round trips) pattern becomes expensive on constrained networks and adds latency in multi-tier architectures.
What GraphQL brings to the table
GraphQL, developed internally at Facebook and open-sourced in 2015, shifts control of the data shape from the server to the client. Instead of calling fixed endpoints, a client sends a query describing exactly the fields it wants, and the server returns precisely that structure. The mobile client in the example above can fetch the user name, recent orders, and delivery status in a single request.
This query flexibility solves the over-fetching and under-fetching problem cleanly, which is why GraphQL gained traction first in complex product apps with multiple consumer types: mobile, web, and third-party integrations all consuming the same graph. A single GraphQL endpoint exposes the full data model; consumers self-serve the slice they need.
GraphQL also ships with a strongly typed schema. Every field, argument, and relationship is declared upfront, which makes tooling excellent. Editors can autocomplete queries, introspection lets clients discover the API shape at runtime, and schema changes can be validated automatically. For teams building developer-facing products or internal platforms with many consumers, this contract-driven approach reduces miscommunication between front-end and back-end squads.
Where each approach struggles
GraphQL's flexibility is also its cost centre. Because clients can request arbitrary query shapes, the server cannot cache responses the way a CDN caches a REST resource. You lose the free layer of HTTP caching almost entirely, and you need to implement your own caching strategy, usually via persisted queries or a tool like Apollo's server-side cache. For public APIs serving millions of anonymous reads, this is a significant operational overhead.
Query complexity is another concern. A poorly constructed GraphQL query can trigger deeply nested resolver chains and generate expensive database joins. REST endpoints, by contrast, are hand-crafted; a backend developer decides exactly what work each endpoint does. Rate limiting, depth limiting, and query cost analysis are all problems REST does not have that GraphQL teams must solve deliberately.
REST, for its part, struggles with versioning at scale. When a field changes or a resource shape evolves, teams have to make a choice between breaking existing consumers, maintaining parallel versions, or extending resources in ways that accumulate technical debt. There is no single standard; different organisations handle REST versioning very differently, which can frustrate third-party developers integrating with a public API.
The Australian context: what teams are choosing in 2026
Across Australian engineering teams in 2026, REST remains the dominant choice for external-facing and public APIs. Government agencies, fintech platforms, and mid-market SaaS companies building integrations with third parties overwhelmingly prefer REST for its simplicity, its alignment with OpenAPI tooling, and the lower barrier for partners to integrate. The DevSecOps practices now standard in Australian product teams also tend to favour REST for public surfaces, because it is easier to apply security controls, audit HTTP traffic, and enforce rate limits at the gateway level.
GraphQL is gaining ground in product-centric companies with complex front-end requirements. Organisations building multi-platform consumer products (web, iOS, Android) or internal developer platforms are finding that GraphQL reduces coordination overhead between squads. That said, the operational maturity required for production GraphQL, schema registries, federated supergraphs, and query performance tooling, means smaller teams often defer to REST until they hit genuine scaling pain.
The choice is rarely binary in practice. Many organisations run both: a REST API for external partners and a GraphQL layer for internal product consumption. This is sometimes called the "BFF" (backend for frontend) pattern, and it lets teams use each tool where it genuinely excels.
A practical decision framework
Before choosing, answer these questions honestly:
- Who are the primary consumers? External developers and partners almost always prefer REST. Internal front-end squads building complex UIs benefit more from GraphQL.
- How important is HTTP caching? Public content APIs, product catalogues, and read-heavy endpoints get enormous value from edge caching. GraphQL makes this harder without extra tooling.
- How many different consumers will shape their own queries? If ten different clients need different slices of the same data, GraphQL pays off. If there are two or three fixed use cases, REST endpoints are simpler.
- What is the team's operational experience? GraphQL in production requires deliberate governance. Introducing it to a team without that experience is a hidden risk.
- Are there strict performance budgets? Mobile apps on constrained networks benefit from GraphQL's reduced payload sizes. Server-to-server internal APIs where latency is less sensitive may not.
If you are building anything that touches AI-assisted features or integrates with a larger data platform, it is also worth reading about what Australian enterprise teams are actually doing with generative AI, since the data-fetching patterns for LLM-backed features often tip the scales toward GraphQL's flexible query model.
Tooling and ecosystem in 2026
The tooling ecosystem for both approaches is mature. REST is well served by OpenAPI 3.x, Swagger UI, Postman, and a generation of API gateways including Kong, AWS API Gateway, and Azure API Management. GraphQL's ecosystem centres on Apollo (Server and Client), Strawberry for Python, Hot Chocolate for .NET, and Hasura for data-layer auto-generation. The recently released GraphQL 2025 spec brought incremental delivery improvements and better handling of deferred fragments, which has reduced some of the latency arguments that used to favour REST on slow connections.
For teams evaluating the language angle alongside the API design question, the Python vs JavaScript comparison is worth reading, since your language choice will influence which GraphQL or REST libraries feel native to your stack.
Neither REST nor GraphQL is the universally correct answer. The teams that make the best choice are the ones who understand their specific consumer needs, their caching requirements, and their team's operational capacity before committing to a direction. Start with REST if you are unsure; it is easier to layer GraphQL on top later than to retrofit REST discipline onto a sprawling schema.