When interviewers ask you to compare REST and GraphQL, they’re looking for three things: a clear definition, an understanding of how each works under the hood, and the ability to weigh trade‑offs in real‑world scenarios. Below is a compact framework you can use, plus a concrete example and a 60‑second spoken version you can rehearse with Call Assistant.

One‑Sentence Definitions

  • REST: A style of web API that maps resources to URLs and uses HTTP verbs (GET, POST, PUT, DELETE) to perform operations.
  • GraphQL: A query language and runtime that lets clients request exactly the data they need from a single endpoint.

How They Work

REST Mechanics

  1. Endpoints – Each resource (e.g., /users/123) has its own URL.
  2. Verbs – The HTTP method tells the server what to do (GET reads, POST creates, etc.).
  3. Representations – The server returns a fixed representation, often JSON, defined by the endpoint.
  4. Caching – Because URLs are stable, browsers and CDNs can cache responses automatically.

GraphQL Mechanics

  1. Single Endpoint – Typically /graphql, handling all queries and mutations.
  2. Schema – A type system (written in SDL) describes every possible field and relationship.
  3. Query Language – Clients send a JSON‑encoded query that specifies exactly which fields they want.
  4. Resolver Functions – The server maps each requested field to a function that fetches data, often chaining multiple data sources.

Trade‑offs

AspectRESTGraphQL
FlexibilityFixed payloads; adding a new field often requires a new endpoint or version.Clients shape responses; adding a field rarely changes the client code.
Over‑/Under‑FetchingCommon to receive more or less data than needed.Precise selection eliminates waste.
CachingStraightforward with HTTP caching headers.Requires explicit client‑side caching or persisted queries.
ComplexitySimple to implement; good for CRUD‑heavy services.Higher learning curve; resolver stitching can become intricate.
ToolingBroad support in browsers, proxies, and API docs.Strong IDE support (e.g., GraphQL Playground) but tooling varies by language.

When to Choose Which

  • Use REST when the API is primarily CRUD‑oriented, you need fine‑grained caching, or the team prefers minimal abstraction.
  • Use GraphQL when the client needs to combine data from many services, bandwidth is limited, or you want to avoid versioning.

Concrete Example

Imagine a dashboard that shows a user's profile and their recent orders.

REST Approach

GET /users/42        # returns user details
GET /users/42/orders # returns an array of orders

The client makes two round‑trips, each returning a fixed shape.

GraphQL Approach

query UserWithOrders($id: ID!) {
  user(id: $id) {
    name
    email
    orders(limit: 5) {
      id
      total
      status
    }
  }
}

A single request fetches exactly the fields needed for the UI, reducing latency.

Typical Interview Questions

  1. "What problem does GraphQL solve that REST doesn’t?" – Emphasize over‑/under‑fetching and the ability to evolve the schema without breaking existing clients.
  2. "How do you handle caching in GraphQL?" – Mention client‑side cache libraries (e.g., Apollo) and persisted queries, noting that HTTP caching is less automatic than with REST.
  3. "Can you mix REST and GraphQL in the same system?" – Yes; many teams keep legacy REST endpoints while exposing a GraphQL gateway for new features.
  4. "What are the security considerations?" – Both rely on authentication headers, but GraphQL can expose a larger surface if resolvers aren’t properly guarded.
  5. "How does error handling differ?" – REST uses HTTP status codes; GraphQL returns a errors array alongside partial data.

60‑Second Spoken Answer

"REST is an architectural style where each resource gets its own URL and you use HTTP verbs to act on it. It’s simple, cache‑friendly, and works well for classic CRUD operations. GraphQL, on the other hand, gives you a single endpoint and a query language that lets the client ask for exactly the fields it needs. This eliminates over‑ and under‑fetching, which is handy when a UI pulls data from many services. The trade‑off is added complexity: you need to define a schema, write resolver functions, and handle caching manually. In practice I choose REST for straightforward data models and GraphQL when the client needs a flexible, bandwidth‑efficient view of the data. For example, a dashboard that shows a user profile and their recent orders can be built with two REST calls or a single GraphQL query that returns only the fields the UI displays."

Practice this aloud a few times; Call Assistant can capture your pacing and suggest minor edits while keeping the story anchored in your own project experience.

How to Practice This

  1. Write the answer on paper – Draft the spoken version without looking at notes, then compare to the template.
  2. Record yourself – Use a phone or laptop recorder; aim for 45‑90 seconds.
  3. Run a mock interview – Ask a colleague to play the interviewer, focusing on the typical questions above. Use Call Assistant to surface follow‑up prompts and keep the conversation on track.

FAQ

  1. Q: Is GraphQL a replacement for REST? A: Not universally. It excels at flexible data fetching, but REST remains a solid choice for simple, cache‑heavy services.
  2. Q: Can I expose both REST and GraphQL from the same server? A: Yes. Many organizations keep legacy REST endpoints while adding a GraphQL gateway for new features.
  3. Q: How does versioning work in GraphQL? A: Instead of versioned URLs, you evolve the schema by adding new fields and deprecating old ones; clients continue to query what they need.
  4. Q: What tooling should I learn first? A: For REST, focus on HTTP basics and API documentation tools like OpenAPI. For GraphQL, start with the schema definition language (SDL) and a client library such as Apollo or Relay.

Frequently asked questions

Is GraphQL a replacement for REST?

Not universally. GraphQL shines when you need flexible queries and want to avoid over‑ or under‑fetching, while REST stays simpler for straightforward CRUD services and benefits from built‑in HTTP caching.

Can I expose both REST and GraphQL from the same server?

Yes. Many teams keep existing REST endpoints for stability and add a GraphQL layer for new, data‑intensive features, letting each client choose the best approach.

How does versioning work in GraphQL?

GraphQL avoids URL versioning. You evolve the schema by adding new fields and marking old ones as deprecated; clients continue to request only the fields they need.

What tooling should I learn first for each approach?

For REST, master HTTP verbs, status codes, and OpenAPI documentation. For GraphQL, start with the schema definition language (SDL) and a client library like Apollo or Relay.

#concept#REST vs GraphQL#technical interview#API design#software engineering