REST vs GraphQL Interview Questions

February 26, 2026 • By Surya Singh • REST • GraphQL • API • Interview

REST vs GraphQL interview questions — API design, over-fetching, schema evolution.

RESTGraphQLAPIInterview

Key Takeaways

  • 1REST: resource-based URLs, standard HTTP methods, stateless; clients may over-fetch or under-fetch.
  • 2GraphQL: single endpoint, client specifies exact fields; flexible but adds complexity and potential N+1.
  • 3REST suits simple CRUD and caching; GraphQL suits flexible client needs and reducing round trips.
  • 4Choose based on team experience, client needs, and operational complexity.

The questions below are commonly asked in technical interviews. Each answer is written to help you understand the concept clearly and explain it confidently. Focus on understanding the "why" behind each answer—that is what interviewers care about.

In this guide

Interview Questions & Answers

What is the main difference between REST and GraphQL?

REST exposes resources as URLs (e.g., /users, /users/1) and uses HTTP methods (GET, POST, PUT, DELETE). The client gets whatever the API returns for that URL—you might get more data than needed (over-fetching) or need multiple requests (under-fetching). GraphQL has one endpoint; the client sends a query specifying exactly which fields it needs. The server returns only those fields. GraphQL is more flexible for clients with varying needs (mobile vs web) but requires a schema, resolvers, and careful design to avoid N+1 and abuse.

// REST - HttpClient
var client = new HttpClient { BaseAddress = new Uri("https://api.example.com") };
var user = await client.GetFromJsonAsync<User>("/users/123");
// Returns full user object - may over-fetch

// GraphQL - single endpoint, client specifies fields
var query = @"query { user(id: 123) { id name email } }";
var body = new { query };
var response = await client.PostAsJsonAsync("/graphql", body);
// Returns only id, name, email

When would I choose REST over GraphQL?

Choose REST when your API is simple (CRUD, few resources), caching with HTTP (Cache-Control, ETag) is important, or your team is more familiar with REST. REST is easier to understand, debug with standard tools, and cache at the CDN or HTTP layer. It fits well when clients have similar needs and over-fetching is acceptable. Many public APIs are REST because of its simplicity and wide support.

When would I choose GraphQL over REST?

Choose GraphQL when clients need different shapes of data (mobile needs few fields, dashboard needs many), you want to reduce round trips (get user + posts + comments in one request), or you have a complex domain with nested resources. GraphQL excels when the client drives the data shape. It also helps when you aggregate multiple backends (BFF pattern). The downside: caching is harder, and you must guard against expensive queries (query complexity, depth limiting).

What is the N+1 problem in GraphQL and how do I solve it?

For a query like "users with their posts," a naive resolver fetches users, then for each user fetches posts—N+1 database queries (1 for users, N for posts). Fix: DataLoader, which batches and caches. When the posts resolver runs for multiple users, DataLoader collects the user IDs, does one batched query (WHERE user_id IN (...)), and distributes results. DataLoader also caches within a request, so duplicate fields do not cause duplicate queries. Batching and caching are essential for GraphQL at scale.

How do I prevent abusive or expensive GraphQL queries?

Use query complexity analysis: assign a cost to each field (scalar = 1, nested = multiplied), limit total complexity per query. Limit query depth (e.g., max 5 levels) to prevent deeply nested queries. Use rate limiting per client. Implement persisted queries: only allow pre-approved queries (by hash), so clients cannot send arbitrary expensive queries. Use timeouts and resource limits. Monitor slow queries and ban or throttle abusive patterns.

Loading...

XLinkedInFacebook
Surya Singh

Surya Singh

Azure Solutions Architect & AI Engineer

Microsoft-certified Azure Solutions Architect with 8+ years in enterprise software, cloud architecture, and AI/ML deployment. I build production AI systems and write about what actually works—based on shipping code, not theory.

  • Microsoft Certified: Azure Solutions Architect Expert
  • Built 20+ production AI/ML pipelines on Azure
  • 8+ years in .NET, C#, and cloud-native architecture
LinkedInTwitter/XAbout Me