REST API knowledge is a staple of backend and full-stack interviews. Whether you're a fresher or a senior engineer, expect questions on HTTP semantics, API design, authentication, and the trade-offs behind a well-designed interface. This guide covers the most common REST API interview questions with concise, interview-ready answers.
REST fundamentals
What is REST, and what makes an API RESTful?
REST (Representational State Transfer) is an architectural style. A RESTful API is stateless, organized around resources identified by URIs, uses standard HTTP methods for actions, and returns standard status codes. Bonus points for mentioning a uniform interface and cacheability.
Explain the main HTTP methods.
- GET — retrieve a resource (safe, idempotent).
- POST — create a resource (not idempotent).
- PUT — replace a resource (idempotent).
- PATCH — partially update (not necessarily idempotent).
- DELETE — remove a resource (idempotent).
What does idempotency mean and why does it matter?
An idempotent request produces the same result no matter how many times it's sent. It matters for retries: a network timeout can safely retry a PUT or DELETE without side effects, but retrying a POST may create duplicates — which is why idempotency keys exist.
Status codes
- 2xx success — 200 OK, 201 Created, 204 No Content.
- 3xx redirection — 301, 304 Not Modified.
- 4xx client error — 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422 Unprocessable, 429 Too Many Requests.
- 5xx server error — 500, 502, 503.
A classic trap: the difference between 401 (not authenticated) and 403 (authenticated but not allowed).
Authentication and security
- Difference between authentication and authorization.
- How do JWTs work, and what are their trade-offs vs session cookies?
- What is OAuth 2.0 at a high level?
- How do you protect an API — HTTPS, rate limiting, input validation, CORS, and avoiding sensitive data in URLs?
API design
- How do you design resource URIs? (Nouns, plural, hierarchical:
/users/123/orders.) - How do you handle versioning — URI (
/v1/) vs header-based? - How do you implement pagination — offset vs cursor-based, and when to use each?
- How do you handle errors consistently with a structured error body?
- REST vs GraphQL — when would you choose each?
The senior question: design an API
Expect an open-ended design prompt: "design the API for a URL shortener" or "design a payments API." Clarify requirements, define the resources and endpoints, choose status codes, handle auth, pagination, rate limiting, and idempotency — and explain your trade-offs out loud. This is where senior candidates separate themselves.
Rehearse explaining your design choices
REST questions quickly become a conversation — "why did you choose cursor pagination?", "what happens if this POST is retried?" Reciting definitions won't carry you through the follow-ups. Greenroom runs spoken backend mock interviews that ask API-design questions and probe your reasoning, with feedback on clarity and depth. See also talking about your GitHub projects in interviews.
Frequently asked questions
What are the most common REST API interview questions?
The most common cover what makes an API RESTful, the HTTP methods and their idempotency, status codes (especially 401 vs 403), authentication with JWTs and OAuth, API versioning, pagination strategies, consistent error handling, and an open-ended API design question for senior roles.
What is idempotency in REST and why is it important?
An idempotent operation produces the same result no matter how many times it's called. GET, PUT, and DELETE are idempotent; POST is not. It matters for safe retries — a client can retry a timed-out PUT without side effects, but retrying a POST may create duplicates, which is why idempotency keys are used for operations like payments.
What's the difference between 401 and 403 status codes?
401 Unauthorized means the request lacks valid authentication — the server doesn't know who you are. 403 Forbidden means you're authenticated but not allowed to access the resource — the server knows who you are and is refusing. This distinction is a common interview trap.
How do I prepare for a REST API design interview?
Practise designing an API out loud for a prompt like a URL shortener or a payments service: clarify requirements, define resources and endpoints, choose status codes, and address authentication, pagination, rate limiting, and idempotency while explaining your trade-offs. Anchoring answers in APIs you've actually built makes the strongest impression.