REST for simple CRUD APIs, public APIs, and when you want simplicity. GraphQL for complex data requirements, mobile apps, and when clients need flexible queries.

Side-by-side

	REST	GraphQL
Data fetching	Fixed endpoints, fixed shape	Client specifies exactly what it needs
Over-fetching	Common (get all fields)	Never (request only needed fields)
Under-fetching	Common (multiple requests)	Never (get everything in one request)
Endpoints	Many (/users, /posts, /comments)	One (/graphql)
Caching	Easy (HTTP caching)	Harder (single endpoint)
Learning curve	Low	Medium
Tooling	Minimal	Requires schema, resolvers, client
File uploads	Simple	Complex
Real-time	Webhooks, SSE	Subscriptions (built-in)

The core difference

REST — you get what the server decides to send:

GET /api/users/1
→ { id: 1, name: "Alice", email: "...", bio: "...", avatar: "...", 
    created_at: "...", updated_at: "...", settings: {...} }

// You only needed name and email. Got everything.
// Now you need their posts too — another request:
GET /api/users/1/posts

GraphQL — you ask for exactly what you need:

query {
  user(id: 1) {
    name
    email
    posts {
      title
    }
  }
}
// One request. Only the fields you asked for.

Where REST wins

• Simplicity — easier to build, easier to understand, easier to debug.
• Caching — HTTP caching works out of the box. CDNs understand REST.
• File uploads — just POST a multipart form.
• Public APIs — REST is the standard. Everyone knows how to use it.
• Small teams — less infrastructure overhead.

Where GraphQL wins

• Complex UIs — dashboards, mobile apps, and pages that pull data from many sources.
• Mobile apps — minimize data transfer (important on slow connections).
• Multiple clients — web, mobile, and third-party clients all query the same API differently.
• Rapid iteration — frontend can change data requirements without backend changes.
• Type safety — the schema is a contract between frontend and backend.

The honest take

Most apps should start with REST. It’s simpler, and you can always add GraphQL later. GraphQL shines when you have complex, nested data requirements and multiple clients consuming the same API differently.

If you’re building a simple CRUD app with one frontend — REST. If you’re building a complex app with mobile + web + third-party consumers — consider GraphQL.

See also: What is REST API? | What is GraphQL? | cURL cheat sheet