REST vs GraphQL Interview Questions and Answers (2026)

When interviewers ask about REST versus GraphQL they’re looking for three things: a clear mental model of each approach, awareness of the practical implications for a production system, and evidence that you can apply that knowledge to real projects. Below is a ladder of questions you might encounter, from entry‑level to senior‑level, each paired with a short answer you could deliver in 45‑90 seconds. After each answer, a typical follow‑up is listed so you can anticipate the next step.

1. Core Concepts

What is REST, and how does it differ from GraphQL?

REST (Representational State Transfer) is an architectural style that uses fixed endpoints—usually one per resource—and standard HTTP verbs (GET, POST, PUT, DELETE) to describe actions. The shape of the response is defined by the server; the client can only request the whole representation.

GraphQL, on the other hand, is a query language that lets the client specify exactly which fields it needs, all through a single endpoint. The server resolves the query and returns a JSON payload that matches the requested shape.

Typical follow‑up: "Can you give an example of a request in each style?"

How does caching work in REST versus GraphQL?

REST leverages HTTP caching semantics (ETag, Cache‑Control) because each URL uniquely identifies a resource version. Browsers and CDNs can store responses automatically.

GraphQL queries are usually POST requests to a single URL, so HTTP caching is less straightforward. Caching is often handled at the resolver level (e.g., DataLoader, Apollo Cache) or via persisted query hashes.

Typical follow‑up: "What strategies do you use to mitigate the caching gap in GraphQL?"

2. Request Shape & Bandwidth

Why might a client prefer GraphQL for a mobile app?

Mobile networks often have limited bandwidth and high latency. GraphQL lets the client ask for only the fields it will actually render, cutting down payload size. This is especially useful when a screen needs a subset of a large object—say, a user profile with just a name and avatar instead of the full address list.

Typical follow‑up: "What are the downsides of that approach?"

When is REST more efficient than GraphQL?

If the client consistently needs the full representation of a resource, a single GET request to a REST endpoint can be simpler and cheaper. Because the response can be cached at the CDN edge, repeated calls may be served without hitting your backend at all.

Typical follow‑up: "How do you decide which pattern to use for a new service?"

3. Versioning & Evolution

How does versioning differ between REST and GraphQL?

REST often introduces a new version in the URL (e.g., /v2/users) when the contract changes in an incompatible way. This can lead to multiple live versions.

GraphQL encourages additive changes: you add new fields or types, and existing queries keep working. Deprecation directives let you signal that a field will be removed in a future major version, but the client can stay on the same schema until it updates.

Typical follow‑up: "What happens if you need to break backward compatibility in GraphQL?"

4. Tooling & Ecosystem

What tooling support exists for GraphQL that REST lacks?

GraphQL benefits from a strong ecosystem: schema introspection, automatic client code generation (e.g., GraphQL Code Generator), and IDE plugins that provide autocomplete and validation. REST has OpenAPI/Swagger, which offers similar capabilities, but the experience is generally less dynamic because the contract is static.

Typical follow‑up: "How do you keep the OpenAPI spec in sync with your code?"

How do you monitor performance in a GraphQL service?

Because a single endpoint can execute many resolvers, you need resolver‑level metrics. Tools like Apollo Engine or OpenTelemetry can instrument each field resolution, giving you latency breakdowns per type. In REST you typically monitor endpoint latency as a whole.

Typical follow‑up: "Can you share a concrete metric you tracked and how you acted on it?"

5. Security Considerations

What security risks are unique to GraphQL?

GraphQL’s flexibility can lead to expensive queries (deep nesting, large result sets). To mitigate this you enforce query depth limits, complexity scoring, and rate limiting. REST’s fixed endpoints make it easier to predict request cost, but you still need to guard against injection and over‑exposure.

Typical follow‑up: "Describe a time you throttled a problematic query."

How do you handle authentication and authorization in both styles?

Both typically use JWT or OAuth tokens passed in the Authorization header. In REST you often protect each endpoint with middleware. In GraphQL you usually attach the user context once per request, then each resolver checks permissions, sometimes via a directive (@auth).

Typical follow‑up: "Which approach gave you finer‑grained control, and why?"

6. Scaling & Architecture

How does the server architecture differ for GraphQL vs REST?

REST services can be split by resource, each with its own controller and database access layer. GraphQL often sits behind a thin gateway that delegates to multiple micro‑services via resolvers. This can add a layer of indirection but also centralises cross‑cutting concerns (logging, auth).

Typical follow‑up: "What patterns do you use to avoid N+1 queries in GraphQL?"

When would you choose a hybrid approach?

Many teams expose a REST API for public, cache‑heavy use cases, and a GraphQL endpoint for internal tools that need flexible data shapes. This lets you keep CDN caching for stable resources while giving developers the agility of GraphQL for dashboards.

Typical follow‑up: "How do you keep the two APIs consistent?"

7. Sample Answers (Spoken Templates)

Below are concise answer templates you can adapt with your own experience. Keep the tone conversational, and anchor each story in a concrete project from your résumé.

Question: "Why would you pick GraphQL for a reporting dashboard?"

"In my last role we built an analytics dashboard that needed data from three different services—orders, customers, and inventory. With REST we would have to call each service separately and then join the results on the client, which added latency and required a lot of error handling. By introducing GraphQL we gave the front‑end a single endpoint where it could request exactly the fields needed for a particular chart. The payload shrank by about 40 % and the UI became noticeably faster. To keep the query cost under control we added a depth limit and used DataLoader to batch database calls, which eliminated the N+1 problem."

Follow‑up: "What challenges did you run into?"

"The biggest challenge was coordinating schema changes across the three services. We set up a shared schema repository and a CI check that failed if a resolver added a breaking field without a deprecation flag. That kept the contract stable while still allowing us to iterate quickly."

Question: "How do you version a public REST API without breaking existing clients?"

"We followed a URL versioning strategy, starting with /api/v1/. When we needed to change the shape of the User resource, we introduced /api/v2/users while keeping the v1 endpoint live for at least a year. To help clients migrate, we published a Swagger spec for each version and added deprecation warnings in the response headers. This gave downstream teams time to adjust without a hard cut‑over."

Follow‑up: "Did you ever have to support multiple versions simultaneously?"

"Yes, for about six months we ran both v1 and v2 in parallel. Our routing layer used a lightweight middleware that inspected the URL prefix and routed to the appropriate controller set. Once the majority of clients had upgraded, we retired v1 with a brief notice period."

8. How to practice this

1. Create a cheat sheet – list the core differences (cache, versioning, request shape) and write one‑sentence bullet points for each.
2. Record yourself – use a tool like Call Assistant to read a question aloud, answer it, and then let the system suggest the next logical follow‑up. Replay the recording to tighten phrasing.
3. Map each answer to a real project – pick two items from your résumé and write a short story that fits the template. Practice delivering the story until the details flow naturally.

---

FAQ

• Q: Do I need to know both REST and GraphQL for every role? A: Most companies expect familiarity with both, but the depth required depends on the team. For front‑end‑focused positions, GraphQL knowledge is often emphasized; back‑end roles may still rely heavily on REST.
• Q: Is GraphQL always better for mobile apps? A: Not necessarily. If the mobile app consumes a stable, cacheable resource, a simple REST GET can be more efficient and easier to secure.
• Q: How do I avoid over‑engineering with GraphQL? A: Start with a thin schema that mirrors your existing REST resources. Add fields only when you see a clear need for flexibility, and keep resolver logic simple.
• Q: What’s a quick way to compare performance of the two approaches? A: Run a set of representative queries against a staging environment, measuring latency and payload size. Compare the results side‑by‑side to see where each shines.