REST vs GraphQL

REST and GraphQL are two different ways to build APIs. Understanding their differences helps you choose the right tool and explains why GraphQL was created in the first place.

The Overfetching Problem in REST

Overfetching means you receive more data than you asked for. A mobile app showing a user's name on a profile screen calls GET /users/1 and receives the entire user object with 15 fields. The app uses only one of them. That wasted data slows down the app, especially on slow mobile connections.

  Mobile Screen Shows:      REST Returns:
  ------------------        ---------------
  [ Avatar ]                {
  [ John Doe    ]             id: 1,
                              name: "John Doe",
                              email: "john@...",
                              phone: "555-...",
                              address: {...},
                              bio: "...",
                              role: "admin",
                              createdAt: "...",
                              updatedAt: "...",
                              avatar: "...",
                              preferences: {...}
                            }
  App needed 2 fields.
  REST sent 11 fields.  ← Overfetching

The Underfetching Problem in REST

Underfetching means one API call does not give you enough data, so your app makes multiple calls. A blog page needs a post, its author, and its comments. REST forces three separate round trips to three different endpoints.

  Page Needs:               App Must Call:
  -----------               --------------
  Post title                GET /posts/5
  Author name               GET /users/3
  All comments              GET /posts/5/comments

  3 HTTP requests for 1 page = slow loading

GraphQL solves both problems. You describe the exact shape of data you need in one request, and the server returns precisely that.

Side-by-Side Comparison

  Feature              REST                  GraphQL
  -------              ----                  -------
  Endpoints            Many (/users,          One (/graphql)
                        /posts, etc.)
  Data fetching        Fixed response         Ask for exact fields
  Over-fetching        Common problem         Eliminated
  Under-fetching       Needs multiple calls   One query does it
  Versioning           /v1/, /v2/ in URL      Schema evolves in-place
  Documentation        Manual (Swagger)       Auto from schema
  Real-time            Polling or WebSocket   Built-in subscriptions
  Learning curve       Lower                  Moderate
  File uploads         Easy                   Requires extra setup

When REST Still Makes Sense

REST works well for simple CRUD apps, public APIs used by many different clients, file upload-heavy applications, and teams with strong existing REST knowledge. GraphQL adds complexity, and that complexity is only worth it when your data needs are varied or your clients have different data requirements.

When GraphQL Shines

GraphQL is the right choice when multiple clients (web, iOS, Android) need different shapes of the same data. It also fits when you want to reduce the number of API calls a mobile app makes, or when your product evolves quickly and you need the API schema to evolve without breaking old clients.

Both Can Coexist

Many companies run REST and GraphQL side by side. A GraphQL layer can sit on top of existing REST services, translating GraphQL queries into REST calls behind the scenes. You do not need to rewrite everything to adopt GraphQL.