REST vs. GraphQL Performance and API Design

REST and GraphQL are two popular ways to design APIs, but the comparison is more nuanced than saying one is faster than the other. REST organizes an API around resources and HTTP semantics. GraphQL exposes a typed schema and lets clients request the fields they need.

That difference can have a major effect on payload size and the number of network requests an application makes. But payload size is only one part of performance. Caching, resolver behavior, database access, query complexity, latency and infrastructure all matter too.

REST vs. GraphQL at a glance

How REST APIs work

REST, or Representational State Transfer, was described by Roy Fielding in his 2000 doctoral dissertation. REST is an architectural style rather than a wire protocol or formal API specification.

A RESTful API typically models data as resources identified by URLs. HTTP methods then express common operations. For example:

GET    /api/landpads
GET    /api/landpads/LZ-2
POST   /api/landpads
PUT    /api/landpads/LZ-2
DELETE /api/landpads/LZ-2

REST APIs frequently exchange JSON, although REST itself does not require JSON. XML, text and other representations can also be used.

A REST response for a landing pad might look like this:

{
  "attempted_landings": 3,
  "details": "Landing Zone 2 at Cape Canaveral",
  "full_name": "Landing Zone 2",
  "id": "LZ-2",
  "landing_type": "RTLS",
  "location": {
    "latitude": 28.485833,
    "longitude": -80.544444,
    "name": "Cape Canaveral",
    "region": "Florida"
  },
  "status": "active",
  "successful_landings": 3,
  "wikipedia": "https://en.wikipedia.org/wiki/Landing_Zones_1_and_2"
}

If a client only needs the landing pad's name and Wikipedia URL, an endpoint with a fixed response representation may return considerably more data than the client needs. This is commonly called over-fetching.

However, over-fetching is not an unavoidable property of REST. A REST API can provide specialized resources, filtering, sparse fieldsets or query parameters that let clients request smaller representations. The tradeoff is that these capabilities must be designed into the API.

How GraphQL changes the request

GraphQL takes a different approach. The API publishes a typed schema, and the client sends a query that describes the shape of the response it wants.

If the client only needs two fields, the query can ask for exactly those fields:

query {
  landpads {
    fullName
    wikipedia
  }
}

A matching response can contain only the requested data:

{
  "data": {
    "landpads": [
      {
        "fullName": "Landing Zone 1",
        "wikipedia": "https://en.wikipedia.org/wiki/Landing_Zones_1_and_2"
      },
      {
        "fullName": "Landing Zone 2",
        "wikipedia": "https://en.wikipedia.org/wiki/Landing_Zones_1_and_2"
      }
    ]
  }
}

This ability to select fields is one of GraphQL's biggest advantages. It is particularly useful for mobile applications and complex user interfaces where different screens need different subsets of the same underlying data.

Does GraphQL perform better than REST?

GraphQL can produce a smaller response when a REST endpoint would otherwise return unnecessary fields. A smaller payload can reduce network transfer and JSON parsing work. GraphQL can also combine related data into one request that might require several REST calls.

But that does not mean GraphQL is inherently faster than REST.

A small GraphQL payload can still be expensive to produce. A poorly implemented resolver may trigger many database queries, including the well-known N+1 query problem. A deeply nested GraphQL request can also consume substantial CPU, memory and database resources even if the JSON response itself is small.

REST can be extremely fast when endpoints map cleanly to cached resources, database queries are efficient and HTTP caching is used effectively.

REST caching vs. GraphQL caching

REST has an important operational advantage: it aligns naturally with HTTP infrastructure. A resource retrieved with a GET request has a URL, which makes browser caches, CDNs, reverse proxies, ETags and standard HTTP cache-control headers straightforward to use.

GraphQL commonly sends queries to one endpoint, often with POST requests. That does not prevent caching, but cache behavior is less directly tied to unique resource URLs. GraphQL applications frequently use normalized client caches, persisted queries, CDN integrations or application-specific server caching instead.

GraphQL can reduce multiple API calls

Payload size is not the only reason developers choose GraphQL. Consider a screen that needs a customer, the customer's recent orders and the products in those orders.

A REST application might make several requests:

GET /customers/42
GET /customers/42/orders
GET /orders/1001/items
GET /orders/1002/items

A GraphQL API can potentially retrieve the required graph of related data in one request:

query {
  customer(id: 42) {
    name
    orders(limit: 2) {
      id
      items {
        productName
        quantity
      }
    }
  }
}

Reducing network round trips can matter significantly when latency is high. The server still has to retrieve the underlying information efficiently, so GraphQL does not eliminate backend performance concerns. It moves more responsibility into the GraphQL execution layer.

GraphQL schema advantages

A GraphQL API is built around a strongly typed schema. Clients can inspect the schema, discover available fields and arguments, and use tooling that validates queries before they are sent.

type Landpad {
  id: ID!
  fullName: String!
  status: String
  wikipedia: String
}

type Query {
  landpads: [Landpad!]!
  landpad(id: ID!): Landpad
}

REST APIs can provide similarly strong contracts through OpenAPI and related tooling, but the schema is not an intrinsic requirement of REST itself.

GraphQL performance challenges

The flexibility GraphQL gives clients also creates challenges for API operators. A server may need protection against queries that are excessively deep, wide or computationally expensive.

Production GraphQL systems commonly consider:

• Query depth and complexity limits.
• Pagination limits.
• Resolver batching and caching.
• Protection against N+1 database queries.
• Authorization at appropriate schema and business-logic boundaries.
• Rate limiting or other resource-consumption controls.
• Persisted or trusted documents when appropriate.
• Observability for individual operations and resolvers.

When should you use REST?

REST remains an excellent choice when an API has clear resource boundaries, straightforward CRUD operations and response representations that work well for most clients. It is also attractive when standard HTTP caching and simple operational behavior are priorities.

For many public APIs, microservices and relatively simple application backends, REST is easy to understand, easy to test and supported by an enormous ecosystem of tools.

When should you use GraphQL?

GraphQL becomes especially compelling when clients need many different views of interconnected data. It can work well when web, mobile and other clients have significantly different data requirements, or when a user interface would otherwise need to orchestrate many API calls.

GraphQL is also attractive when schema introspection, typed client tooling and client-controlled field selection provide meaningful development advantages.

REST vs. GraphQL: Which is better?

Neither architecture wins every REST vs. GraphQL comparison.

GraphQL can reduce over-fetching and network round trips, but those benefits do not automatically translate into better end-to-end performance. REST can take advantage of mature HTTP caching semantics and often has a simpler operational model.

The better choice depends on the shape of your data, the needs of your clients, caching requirements, backend architecture and the complexity your team is prepared to operate.

If clients mostly consume predictable resource representations, REST is often the simpler solution. If clients need flexible combinations of deeply related data, GraphQL can provide a much more expressive API.