Everyone builds REST APIs; few build them well. These questions check whether a candidate understands HTTP semantics and API design, not just returning JSON.
Hiring a REST API developer is easy. Telling a real one from a convincing résumé is the hard part — and it’s most of what we do. These are grouped by level, because the same question that stretches a junior is a warm-up for a senior.
Junior REST API interview questions
0–2 years
HTTP fundamentals.
What makes an API RESTful?
Resources identified by URLs, standard HTTP methods, statelessness, and representations (usually JSON) rather than RPC-style verbs in URLs.
Puts actions like /getUser in the URL.
What do the main HTTP methods mean?
GET reads, POST creates, PUT replaces, PATCH partially updates, DELETE removes; they carry semantics you should honour.
Uses GET or POST for everything.
What are the common HTTP status code categories?
2xx success, 3xx redirection, 4xx client error, 5xx server error; using the right code communicates outcomes.
Returns 200 with an error message in the body.
What is the difference between PUT and PATCH?
PUT replaces the whole resource; PATCH updates part of it.
Uses PUT for partial updates and wipes fields.
What are path parameters vs query parameters?
Path params identify a resource (/users/1); query params filter, sort or paginate (?page=2).
Puts filters in the path and ids in the query.
What is statelessness in REST?
Each request contains all context needed; the server keeps no client session between requests, aiding scalability.
Relies on server-side session state between calls.
What are request and response headers used for?
Metadata like content type, auth, caching and content negotiation.
Ignores headers and content types.
What is the difference between authentication and authorization?
Authentication verifies who you are; authorization decides what you can do.
Conflates the two.
Mid-level REST API interview questions
2–5 years
Design and reliability.
What does idempotency mean and which methods are idempotent?
An idempotent request has the same effect if repeated; GET, PUT and DELETE should be, POST usually isn’t — important for safe retries.
Makes POST retries that double-create records.
How do you version an API?
URL versioning, headers, or additive, backward-compatible changes with deprecation; the goal is not breaking clients.
Breaks existing clients with changes and no versioning.
How do you design pagination?
Cursor/keyset pagination for large, changing datasets over deep offsets, with clear metadata.
Uses large offsets that scan and skip many rows.
How should errors be structured?
Correct status codes plus a consistent body with a machine-readable code and human message, without leaking internals.
Returns stack traces or generic 500s for everything.
How do you secure a REST API?
Auth (tokens/OAuth), HTTPS, input validation, rate limiting, least-privilege scopes, and no secrets in URLs.
Passes tokens in query strings and skips validation.
What is HATEOAS and is it always needed?
Hypermedia links in responses to drive navigation; it’s part of REST purism but often skipped pragmatically.
Presents an opinion with no understanding of the tradeoff.
How do you handle filtering, sorting and searching?
Query parameters with sensible defaults and limits, validated to prevent abuse.
Allows arbitrary, unbounded queries.
How do you make an API backward compatible?
Add fields rather than remove or rename, default new fields, and deprecate gradually with communication.
Renames fields and breaks clients.
Senior REST API interview questions
5+ years
Scale and architecture.
How do you design an API for high traffic?
Caching (HTTP/CDN), pagination, rate limiting, statelessness for horizontal scale, and efficient payloads.
No caching or rate limiting and unbounded payloads.
How do you handle rate limiting and abuse?
Per-client limits with a shared store, clear headers communicating limits, and graceful 429 responses.
In-memory limits that don’t work across instances.
How do you handle long-running operations in a REST API?
Return 202 and a status resource to poll, or use webhooks/async patterns rather than blocking the request.
Blocks the request until a slow job finishes.
When would you choose REST vs GraphQL vs gRPC?
REST for broad compatibility and caching, GraphQL for flexible client-driven queries, gRPC for high-performance internal services.
Insists one is always right.
How do you document and contract-test an API?
A spec (OpenAPI) as the contract, generated docs, and contract tests so producers and consumers stay in sync.
Docs drift from reality and break integrations.
How do you ensure consistency across a large API surface?
Style guides, shared conventions for naming, errors and pagination, and automated linting.
Every endpoint invents its own conventions.
How do you handle caching and concurrency (ETags)?
Cache headers for freshness and ETags/If-Match for optimistic concurrency to prevent lost updates.
Ignores concurrent updates and overwrites data.
How do you evolve a public API responsibly?
Deprecation policies, versioning, telemetry on usage, and clear communication so clients migrate smoothly.
Makes breaking changes with no notice.
Build and score a full interview with our free interview scorecard tool, browse the full question hub, or see how we interview engineers.