GraphQL vs. REST: Which API Style, and When?

REST is an API style with many fixed endpoints; GraphQL is a query language where clients ask one endpoint for just the fields they need. The comparison is really about who decides the response shape: in REST the server decided at design time; in GraphQL the client decides per request. Everything else — caching, versioning, errors, performance — falls out of that one inversion.

Key takeaways

The same screen, both ways

A profile screen needs a user, their five latest posts, and follower count. REST speaks in resources:

GET /users/42               → 38 fields, you needed 3     (overfetching)
GET /users/42/posts?limit=5 → second round trip           (underfetching)
GET /users/42/followers     → third round trip

GraphQL speaks in one shaped question:

POST /graphql
query {
  user(id: 42) {
    name
    avatarUrl
    posts(first: 5) { title likes }
    followers { totalCount }
  }
}
→ one round trip, exactly those fields, nothing else

The gap narrows more than the headlines suggest: well-designed REST supports field selection too — and SDK query builders make it a first-class habit:

// JavaScript / Node.js — Back4app JS SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
const query = new Parse.Query('Article');
query.equalTo('status', 'published');
query.select('title', 'views');        // field selection, GraphQL-style
const articles = await query.find();   // lean payload over the REST API
// The same backend also speaks real GraphQL: query { articles { ... } }

// Flutter / Dart — Back4app Flutter SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
final query = QueryBuilder<ParseObject>(ParseObject('Article'))
  ..whereEqualTo('status', 'published')
  ..keysToReturn(['title', 'views']);   // field selection, GraphQL-style
final response = await query.query();   // lean payload over the REST API

// iOS / Swift — Back4app Swift SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
let query = Article.query("status" == "published")
  .select("title", "views")             // field selection, GraphQL-style
query.find { result in
  if case .success(let articles) = result { render(articles) }
}

// Android / Kotlin — Back4app Android SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
val query = ParseQuery.getQuery<ParseObject>("Article")
query.whereEqualTo("status", "published")
query.selectKeys(listOf("title", "views"))  // field selection, GraphQL-style
query.findInBackground { articles, e -> if (e == null) render(articles) }

GraphQL vs. REST at a glance

The parts the comparison pages skip

The N+1 problem moved, it didn’t die. A GraphQL query for posts-with-authors naïvely fires one resolver call per post — the same N+1 pathology ORMs made famous, now server-side. The standard cure is batching: a per-request loader collects the author IDs and fetches them in one query. Adopting GraphQL without a batching strategy is adopting REST’s worst performance bug at a new address.

Errors are an operations decision. “200 with an errors array” means dashboards, alerting, and CDN logic built on status codes go blind by default. Teams that thrive with GraphQL treat error observability as part of adoption, not an afterthought.

Unbounded queries need bounding. One flexible endpoint means one query can traverse the whole graph — the official security guidance is depth limits, query-cost budgets, and persisted-query allowlists for first-party clients. REST’s fixed endpoints made cost control implicit; GraphQL makes it your job.

Common use cases

• GraphQL: mobile apps on slow networks, dashboards stitching many entities, products with web + mobile + partner clients diverging in data needs, rapid frontend iteration against a stable schema.
• REST: public developer APIs, cacheable content delivery, webhook and integration surfaces, file transfer, service-to-service calls where simplicity wins.
• Both (the enterprise norm): REST or RPC between backend services; a GraphQL layer aggregating them for frontends — the backend-for-frontend pattern with a schema.

Should you choose GraphQL or REST? A decision matrix

The honest default: start REST, add GraphQL when multi-client data-shaping pain actually arrives — and if your platform generates both from one schema, the choice stops being architectural and becomes per-request.

Limitations and trade-offs

• REST: over/underfetching on data-dense screens, version migrations, response-shape drift across teams, and N endpoints of documentation.
• GraphQL: caching requires machinery, cost control requires vigilance, resolvers require batching discipline, and the 200-with-errors pattern requires observability rework.
• Both: neither fixes a bad data model — a confused domain produces a confused API in any style, as the REST dissertation itself quietly implies: the constraints were always about the architecture underneath.

GraphQL and REST on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. It dissolves this article’s dilemma at the root: both API styles are generated from the same schema — URL-cacheable REST endpoints and a typed GraphQL API with nested queries — plus SDKs whose field selection (the code tabs above) delivers GraphQL’s headline benefit over either transport. Pick per client, switch per screen, and never write the API layer at all.