REST vs GraphQL in Practice

The Practical Differences

When I started building APIs, REST was the default. Then GraphQL came along and promised to fix everything. After using both in real projects, I've learned that the choice isn't about which is 'better' but about what fits your use case. Let's break down the practical differences.

REST: Simple and Predictable

REST is built around resources and HTTP methods. You have endpoints like /users and /users/1. Each endpoint returns a fixed shape. It's easy to understand, cache, and debug.

Here's a typical REST call:

// Get user and their posts

const userRes = await fetch('/users/1');

const user = await userRes.json();

const postsRes = await fetch('/users/1/posts');

const posts = await postsRes.json();

Pros:

• Simple to implement and consume


• Built-in caching with HTTP


• Great for public APIs where you control the response shape


• Easy to version (/v1/users)

Cons:

• Over-fetching: you get all fields even if you need one


• Under-fetching: you need multiple requests to get related data


• No way for the client to request exactly what it needs

GraphQL: Flexible but Complex

GraphQL gives the client control over the response. You send a query and get exactly what you ask for.

query {

  user(id: 1) {

    name

    posts {

      title

    }

  }

}

One request gets the user and their posts, with only the fields you need.

Pros:

• No over-fetching or under-fetching


• Single round-trip for complex data


• Strongly typed schema with introspection


• Great for mobile apps where bandwidth matters

Cons:

• More complex to set up and maintain


• Caching is harder (no natural HTTP caching)


• Potential for expensive queries if not careful


• Requires a learning curve for clients

Real-World Considerations

1. Team Experience

If your team knows REST well, introducing GraphQL adds a lot of new concepts: resolvers, schema, fragments, mutations. For a small internal API, REST is often easier.

2. Client Needs

If your clients are mostly web apps with simple data needs, REST is fine. If you have mobile clients with variable network conditions, GraphQL's ability to fetch exactly what's needed is a big win.

3. Performance

REST can be faster for simple requests because of HTTP caching and CDN support. GraphQL can be slower if you have deeply nested queries, but you can mitigate with query complexity limits and DataLoader for batching.

4. Tooling

REST has mature tooling: Swagger, Postman, caching proxies. GraphQL has excellent tools like Apollo and GraphiQL, but they are more complex to set up.

A Hybrid Approach

You don't have to choose one. Many projects start with REST and add GraphQL for specific use cases. For example, you can expose a REST API for public consumption and a GraphQL API for your own frontend. This gives you the best of both worlds.

My Take

For my current project, I used REST for the public API because it's stable and easy for third parties to consume. Internally, the frontend uses GraphQL to avoid multiple round-trips. It adds some complexity, but the improved developer experience is worth it.

If you're starting fresh and your API is mostly for your own clients, GraphQL is a solid choice. If you're building a public API with unknown consumers, REST is safer.

Bottom Line

REST is like a buffet: you get a fixed plate. GraphQL is like ordering à la carte: you pick exactly what you want. Both work, but they fit different situations. Understand your requirements, your team, and your clients before choosing.

Happy coding!