REST vs. GraphQL: It Hurts Less Once You Understand

If you've built even one web app, you've eaten the REST sandwich. GET this, POST that, DELETE the other. GraphQL is the new(ish) kid that claims to fix everything REST does wrong. But here's the thing: they're not fighting to the death. They're solving different problems, and the one you should use depends on what you're building.

So what's the real difference, stripped of buzzwords?

How they think about data

REST treats every piece of data as a "resource" with a fixed URL. You want users? Hit /api/users. Want that user's posts? That's a different endpoint: /api/users/123/posts. The shape of the response is decided by the server, not you.

GraphQL gives you one endpoint—always /graphql—and you ask for exact fields you need in a query. Want user name, email, and the titles of their last five posts? You write that shape in your query, and that's exactly what comes back.

This is the core difference: REST is server-dictated. GraphQL is client-driven.

The practical pain points

Over-fetching (REST's quiet sin)

With REST, when you hit /api/users, you often get back 30 fields when you only need name and avatar_url. That's data you paid for (bandwidth) and are ignoring (memory). Multiply that by thousands of requests, and it adds up.

# REST: I asked for users, got their life story
GET /api/users
# Response: id, name, email, phone, address, created_at, updated_at, 
#           subscription_tier, last_login_ip, and 23 other fields
# I just wanted to display their name.

Under-fetching (REST's other sin)

Now you need a user's posts. REST says: first call /api/users/123, then call /api/users/123/posts (or worse, a separate /api/posts?user=123). That's two round-trips. In GraphQL, one query:

{
  user(id: 123) {
    name
    posts { title, published_at }
  }
}

One request. All data. Client decides what matters.

Caching — REST's killer feature

REST wins here, and it's not close. Each resource has a unique URL, which means HTTP caching just works. You can slap a CDN in front of /api/popular-articles and thousands of users get cached responses. The browser cache, proxy caches, server-side caches—they all understand URLs.

GraphQL caching is harder because every request is unique. Two queries for "user" look different if one asks for { name } and another asks for { name, email }. You can't just cache by URL. You need more sophisticated tools (Apollo, Relay, or rolling your own field-level caching).

When REST wins

• Simple CRUD apps — blogs, CMS, basic dashboards. You don't need the complexity.
• Public APIs — you control the response shape. External developers don't care about over-fetching; they want stable, documented endpoints.
• Heavy caching — serving millions of GET requests? REST's URL-based caching is your best friend.
• You have one client — or clients that all need the same data shape.

When GraphQL wins

• Multiple frontends — iOS wants different data than web? GraphQL lets each client ask for exactly what it needs.
• Complex nested data — social feeds, dashboards with relational data. Avoiding N+1 requests is huge.
• Rapid product iteration — frontend devs can add fields to queries without waiting for a new endpoint.
• You're okay with a server-side caching layer — tools like DataLoader make N+1 problems manageable.

The ugly middle ground

Some teams try to "combine" them. You'll see things like /api/graphql endpoints that actually run REST logic underneath. Sometimes this works. Often it's the worst of both worlds—you lose REST's simplicity and caching, but don't get GraphQL's query flexibility because you've hacked it together.

Don't be that team. Pick one intentionally.

Real talk: What should a Python dev do?

If you're starting a new project and undecided:

• Django + DRF → REST, because DRF is mature, well-documented, and your brain won't melt.
• FastAPI → either works. FastAPI plays nicely with GraphQL libraries like Strawberry or Ariadne.
• Strawberry GraphQL → if you know you'll have multiple clients or complex querying needs. It generates types from GraphQL schemas automatically.
• You're building a tiny script or internal tool → REST with Flask is faster to prototype.

GraphQL isn't "better REST." It's a different tool. REST is a hammer—one thing, works great. GraphQL is a Swiss Army knife—more flexible, but you can cut yourself if you're not careful.

Pick the one that matches your real problem, not the one that sounds cooler on Hacker News.