← Backend interview questions

REST vs GraphQL Interview Questions

REST and GraphQL are both tools; the interview is about fit. REST shines when caches, CDNs, and simple cache keys matter. GraphQL shines when clients need flexible shapes and you are willing to invest in loaders, complexity limits, and observability per resolver. Bad answers dunk on one side; good answers describe a constraint matrix: mobile bandwidth, third-party integrators, admin dashboards, versioning culture, and how your team actually ships schema changes on Fridays.

REST angles to own

GraphQL angles to own

Batching/dataloader patterns, field-level authorization, persisted queries, rate limiting by query cost, and what you log when a client asks for the entire graph accidentally. If you have paged connections with stable cursors, say why offsets lied for your dataset.

Data layer follow-through

APIs sit on top of storage. Pair this topic with SQL vs NoSQL and indexing so you can explain how resolver fan-out translated to database load—and how you proved it in staging before prod melted.

Same data, two shapes: mobile pain vs CDN joy

REST cache-friendly vs GraphQL POST (sketch)

// REST: CDN can cache GET /v2/products?category=shoes
GET /v2/products?category=shoes
ETag: "3fa7c1"
Cache-Control: public, max-age=60

// GraphQL: usually POST + complexity limits
POST /graphql
{ "query": "{ products(category:SHOES){ sku title price{ amount currency } } }" }

Tie to Azure API Management: you might terminate TLS, enforce JWT scopes on REST, and add a depth/cost plugin on GraphQL. Human story: marketing wants flexible fields, SRE wants edge cache hit rate—you negotiate persisted queries or BFF.

Questions with sample answers

These are interview-ready outlines—sound human by swapping in your own metrics, team names, and war stories. The examples are generic on purpose so you can map them to what you actually shipped.

  1. Primary prompt

    Mobile clients need flexible fields but CDN caching matters—sketch a hybrid approach.

    BFF GraphQL for mobile flexibility + REST/GET for public catalog with CDN keys; persist queries for GraphQL cache; separate read models—cache at field resolvers with DataLoader batching.

  2. Primary prompt

    How do you prevent unbounded GraphQL queries without frustrating internal power users?

    Query cost analysis, max depth/complexity, pagination limits, persisted allowlist for production; internal tools higher limits with auth; timeout and cancel.

  3. Primary prompt

    Version a REST API used by hardware devices that update yearly.

    URL version /v1, long deprecation window, additive changes only where possible, feature flags server- side; document sunset with device fleet metrics.

  4. Primary prompt

    Compare error shapes: how does debugging differ when clients use GraphQL vs REST?

    GraphQL returns 200 with errors array + partial data—need client discipline to check errors; REST uses status codes—proxies/CDN behave differently; both need correlation IDs.

Follow-ups interviewers often ask

Expect nested "why?" questions—brief answers here; expand with your production defaults.

  1. Follow-up

    What is your caching story at the edge for each style?

    REST GET + cache headers + ETag shines; GraphQL POST usually bypasses CDN—use GET queries, APQ, or edge functions with care.

  2. Follow-up

    How do you authorize fields in GraphQL without N database round trips?

    Auth at resolver with batched loaders, rule engine on selection set, or declarative schema directives + middleware; avoid per-field sequential DB hits.

  3. Follow-up

    When is OData or JSON:API worth mentioning as a middle ground?

    Enterprise integrations needing consistent filtering/sorting—JSON:API for hypermedia; OData for reporting clients— trade complexity vs flexibility.

  4. Follow-up

    How do you document and enforce pagination limits?

    OpenAPI max limit, default 20, cap 100; return 400 above; cursor-based for large tables.

  5. Follow-up

    What breaking change process do you use for public APIs?

    Deprecation headers, changelog, semver for libraries, customer comms, telemetry on old versions, sunset date with extension policy.