Picking an API style is one of those decisions that feels small in week one and expensive in year two. Teams starting a new web or mobile product, or adding a public API to an existing one, usually narrow it down to REST or GraphQL, then get stuck arguing about which is "better." Neither is better in the abstract. Each one solves a different shape of problem, and the wrong pick shows up later as caching headaches, chatty mobile clients, or a schema nobody wants to touch. This guide walks through what each style actually does well, where each one creates real engineering cost, and how to decide which fits your product.
What REST Actually Means
REST (Representational State Transfer) organizes an API around resources, not actions. A customer is a resource at /customers/42, an order is a resource at /orders/107, and HTTP verbs (GET, POST, PUT, PATCH, DELETE) describe what you want to do to that resource. There is no single REST specification the way there is for GraphQL; REST is a set of architectural constraints described in Roy Fielding's dissertation, and most "REST APIs" in production are really pragmatic interpretations of those ideas layered on top of standard HTTP semantics.
That looseness is part of REST's appeal. Any HTTP client can call a REST endpoint, every CDN and reverse proxy already knows how to cache a GET request, and most engineers can read an endpoint list and understand the API without additional tooling. It is the default for public APIs, webhook receivers, and straightforward CRUD backends because it is boring in the best sense: predictable, debuggable with curl, and well supported by every framework and gateway on the market.
What GraphQL Actually Means
GraphQL takes a different shape. Instead of many endpoints returning fixed payloads, a GraphQL API exposes a single endpoint and a schema that describes every type, field, and relationship available. Clients send a query describing exactly which fields they want, nested however they need, and the server returns exactly that shape, nothing more. A mobile screen that needs a user's name, their last three orders, and each order's shipping status can get all of it in one request instead of three or four round trips to different REST endpoints.
The schema is the contract. It is strongly typed, introspectable, and self-documenting, which is why tools like GraphiQL and Apollo Studio can generate interactive documentation directly from it. That contract also makes it easier to evolve the API without breaking old clients: you add new fields and deprecate old ones in place, rather than shipping a new API version.
Where REST Still Wins
REST tends to come out ahead in a few concrete situations:
- Caching. A GET request maps cleanly onto HTTP caching, CDN edge caching, and browser cache behavior. GraphQL's single POST endpoint does not get any of that for free; caching has to be built into the application layer.
- Public and partner APIs. External developers generally expect REST. It is easier to rate-limit by endpoint, easier to document with OpenAPI, and easier for a partner's engineering team to integrate without learning a query language first.
- Simple, stable data shapes. If most of your endpoints return close to what the client needs most of the time, the overhead of running a GraphQL layer buys you very little.
- Operational maturity. Monitoring, rate limiting, API gateways, and security tooling built for REST are more mature and more widely understood across hosting platforms and security teams.
Where GraphQL Still Wins
GraphQL earns its complexity in situations like these:
- Multiple client types. A web app, an iOS app, and an Android app often need different slices of the same data. REST tends to answer this by multiplying endpoints or adding query parameters for every variation; GraphQL lets each client ask for its own shape from one schema.
- Deeply nested or relational data. A dashboard that pulls from five related resources in one screen is a textbook case for GraphQL's ability to resolve a nested query in a single round trip instead of several sequential REST calls.
- Bandwidth-constrained clients. Mobile apps on inconsistent networks benefit from requesting only the fields a screen actually renders, instead of downloading a full REST payload and discarding most of it.
- Fast-moving frontend teams. When frontend and backend teams ship on different schedules, a GraphQL schema lets frontend engineers adjust what data they pull without backend engineers adding a new endpoint for every change.
The Real Cost of GraphQL: The N+1 Problem
GraphQL's flexibility has a well-known trap on the server side. Say a query asks for ten reviews and each review's associated product. If the resolver for the product field runs independently per review, you get one database or service call per review, ten calls for data that should have taken one. This is the N+1 problem, and it is the single most common performance issue in GraphQL implementations that skip batching from day one.
The standard fix is DataLoader, a batching and caching utility that collects individual key lookups made during a single tick of the event loop and resolves them as one batched query, deduplicating identical keys along the way. Apollo's guide to handling the N+1 problem covers the pattern in detail, and nearly every mainstream GraphQL server library ships a DataLoader implementation. The practical takeaway for planning purposes: budget time for batching strategy during the initial build, not after a production incident reveals it.
GraphQL also makes caching and rate limiting harder than REST does. Because every request hits the same endpoint with a different query, a request-level cache has little to work with, and a single query can request more or less resolver work than another, which complicates straightforward rate limiting by request count. Query complexity analysis and persisted queries address this, but they are additional engineering investment that a REST API typically does not need.
The Real Cost of REST: Over-Fetching and Versioning
REST's costs show up differently. A mobile client that needs three fields from a customer record but gets the full object back is over-fetching; a dashboard that needs data from four endpoints to render one screen is under-fetching and making four round trips to compensate. Neither is fatal, but both add latency and bandwidth on constrained connections.
Versioning is the other recurring REST pain point. Once an endpoint ships, changing its response shape risks breaking existing clients, so teams either version the whole API (/v1, /v2) or add optional fields indefinitely. Both approaches work, but both require discipline that tends to erode as a team grows and ships faster than it documents.
A Practical Decision Framework
Instead of debating REST versus GraphQL in the abstract, answer these questions for your actual product:
- How many distinct client types will consume this API? One web client leans REST. Web, mobile, and third-party partners with different data needs leans GraphQL.
- Is this API public-facing or internal? Public APIs benefit from REST's familiarity and caching story. Internal product APIs tolerate GraphQL's operational overhead more easily because your own team controls both sides.
- Does your team already know GraphQL? A team with no GraphQL experience will spend real time learning schema design, resolver patterns, and batching before they ship anything. That cost is real and should be weighed against the problem GraphQL is meant to solve.
- How relational is the data a single screen needs? Flat, single-resource screens favor REST. Screens that stitch together many related resources favor GraphQL.
- How important is HTTP-level caching to your performance budget? If CDN caching does most of your performance work today, moving to GraphQL removes that lever unless you rebuild caching at the application layer.
Most products do not need a single pure answer. A common and sensible pattern is a backend-for-frontend (BFF): keep a REST API for public integrations, webhooks, and anything that benefits from HTTP caching, and add a GraphQL layer in front of internal services for the product's own web and mobile clients. Some TypeScript-heavy teams reach for tRPC instead of GraphQL for internal APIs when both the client and server live in the same codebase, trading GraphQL's cross-language flexibility for simpler, fully typed end-to-end calls without a schema layer. It is worth knowing that option exists, even though REST and GraphQL remain the two choices most teams actually compare.
None of this is specific to greenfield products. Teams integrating with external systems run into the same fork. FHIR-based EHR integration, for example, is built on REST principles for exactly the reasons above: predictable caching, wide tooling support, and the need for many different healthcare systems to interoperate without agreeing on a shared query language first.
How This Plays Out at Different Scales
For a single-product SaaS company with one web client and a handful of internal services, REST with a clean, versioned API is usually the lower-risk choice, and the architecture questions that matter more are about data isolation and tenancy, covered in our piece on multi-tenant SaaS architecture. For a product with a web app, a native mobile app, and a partner integration program, GraphQL's ability to serve different shapes from one schema starts to pay for its added complexity. And for either path, the API layer is only one piece of a larger performance picture; once traffic grows, the bottlenecks are just as likely to be in the database or caching layer, which is why it is worth reading alongside our guide on scaling a web application.
It also helps to remember that REST and GraphQL both sit on top of the same transport. Understanding HTTP's request-response model and GraphQL's own type system through its official documentation makes the tradeoffs above concrete rather than theoretical, especially for a team evaluating this decision for the first time.
Frequently Asked Questions
Can I switch from REST to GraphQL later without rebuilding everything?
Yes, in most cases. A common migration path adds a GraphQL layer in front of existing REST endpoints or services, resolving GraphQL fields by calling the existing REST logic underneath. This lets a team adopt GraphQL for new clients without rewriting the backend in one step, though it still requires schema design and batching work to do well.
Is GraphQL always slower than REST?
No. Benchmarks are workload-dependent: REST tends to win on raw throughput for simple, high-volume requests, while GraphQL can reduce total latency for screens that would otherwise need several sequential REST calls. The honest answer is that neither style is categorically faster; the bottleneck is usually the database and resolver logic underneath either one.
Do I need GraphQL just because I have a mobile app?
Not necessarily. A mobile app with REST and well-designed, purpose-built endpoints (sometimes called a BFF pattern) can perform just as well as GraphQL without the added operational complexity. GraphQL becomes more compelling when the mobile app's data needs diverge significantly from the web app's, or when a third client is added later.
What does GraphQL do to API security?
It changes the shape of the problem rather than making it harder or easier outright. Field-level authorization, query depth limiting, and query cost analysis replace REST's simpler per-endpoint access control. Both styles can be built securely, but GraphQL requires deliberate limits on query complexity to prevent a single expensive nested query from overloading the backend.
If you are weighing this decision for a new product, an API you are opening to partners, or a mobile app that has outgrown its current backend, it is worth working through the tradeoffs with a team that has built both. Our web application development and SaaS development teams help clients choose and implement the right API architecture before writing the first line of schema or endpoint code. You can book a strategy call to talk through your specific client mix and data model.