These are the REST API questions that actually come up in backend and full-stack interviews — grouped by topic, each with a short model answer and a note on what the interviewer is really checking. API questions reward clarity: they tell an interviewer whether you've designed one or just consumed one.
The giveaway on API questions is whether you reach for the HTTP mechanism or hand-wave. "You'd use a POST" is weaker than "POST, because creating a resource isn't idempotent and shouldn't be cached." For each answer below, notice the pattern: name the mechanism, give the one rule that matters, then stop.
HTTP methods & status codes
What's the difference between GET, POST, PUT, PATCH and DELETE?
They map to intent. GET reads (and must have no side effects). POST creates a new resource or triggers an action. PUT replaces a resource entirely. PATCH updates part of one. DELETE removes it. The property that matters is idempotency: GET, PUT and DELETE are idempotent (calling them twice leaves the same state), POST is not (two POSTs create two resources). That's why a retried POST can double-create and a retried PUT can't.
What they're testing: that you pick a verb by its semantics and idempotency, not habit.
Which status codes do you use, and when?
The families first: 2xx success, 4xx the client's fault, 5xx the server's fault. The ones you should name without thinking: 200 OK, 201 Created (with the new resource), 204 No Content (a successful DELETE), 400 Bad Request (malformed), 401 Unauthorized (not authenticated), 403 Forbidden (authenticated but not allowed), 404 Not Found, 409 Conflict, 422 Unprocessable (validation failed), 429 Too Many Requests, and 500 for an unhandled server error. The classic mistake is returning 200 with an error in the body — the status code is the result.
What they're testing: that you use the status line to carry meaning, especially the 401-vs-403 distinction.
REST design
What actually makes an API "RESTful"?
REST is a set of constraints, and the ones interviewers care about are: resources identified by URLs, standard HTTP verbs for actions on them, and — the big one — statelessness: every request carries everything the server needs, so the server keeps no per-client session between calls. Statelessness is what lets you put any server behind a load balancer and scale horizontally. A representation (usually JSON) is what you actually send over the wire.
What they're testing: that you tie "RESTful" to statelessness and scaling, not just "it returns JSON."
How do you design resource URLs?
Nouns, not verbs, and plural collections: /users, /users/42, /users/42/orders. The HTTP method is the verb, so GET /users/42 — never GET /getUser?id=42. Nest to show a relationship (/users/42/orders) but don't nest more than a level or two, or URLs get unwieldy. Use query parameters for filtering, sorting and pagination (/orders?status=open&sort=-created), not for identity.
What they're testing: that the URL names the resource and the method names the action — the core REST idea.
PUT vs PATCH — what's the difference?
PUT replaces the whole resource — you send the complete representation, and anything you leave out is cleared. PATCH applies a partial update — you send only the fields that change. Practically, PATCH is what you usually want for an "edit"; PUT is for a full overwrite. The subtlety interviewers like: PUT is idempotent (sending the same full body twice is fine), while a carelessly-designed PATCH (say, "increment by 1") may not be.
What they're testing: that you know partial vs full update, and the idempotency corner.
Versioning, pagination & errors
How do you version an API?
You version so you can change the contract without breaking existing clients. The common approaches: a URL prefix (/v1/users) — simplest and most visible; a header or media type (Accept: application/vnd.api+json;version=1) — cleaner URLs but less obvious. URL versioning wins most interviews for being explicit. The real point is that any breaking change — removing a field, renaming one, changing a type — needs a new version; additive changes don't.
What they're testing: that you protect existing clients and know what counts as a breaking change.
How do you paginate a large collection?
Two options. Offset pagination (?limit=20&offset=40) is simple but gets slow on deep pages and can skip or repeat rows if the data changes between requests. Cursor (keyset) pagination (?limit=20&after=<id>) passes a pointer to the last item you saw and queries "the next 20 after this" — it stays fast at any depth and is stable under inserts. Use offset for small admin tables, cursor for large or live feeds.
What they're testing: that you know offset breaks down at scale and cursor is the fix.
How should an API return errors?
With the right status code and a consistent, machine-readable body — a stable error code, a human-readable message, and ideally which field failed: { "error": "validation_failed", "message": "...", "field": "email" }. Consistency is the whole point: a client should be able to handle every error the same way. Don't leak internals (stack traces, SQL) in the message, and don't return 200 for a failure.
What they're testing: that your errors are predictable and safe for a client to program against.
Auth, caching & reliability
How do you authenticate a REST API?
Pick by use case. API keys for server-to-server — simple, long-lived, carried in a header. JWT (bearer tokens) for user sessions in a stateless API — the token is signed and self-contained, so the server verifies it without a lookup, which fits REST's statelessness. OAuth 2.0 when a third party acts on a user's behalf ("sign in with Google," granting another app access). Whatever you choose, it's HTTPS-only and the credential goes in the Authorization header, never the URL.
What they're testing: that you match the auth method to the scenario and never put secrets in a URL.
REST vs GraphQL — when would you use each?
REST exposes resources at fixed endpoints; GraphQL exposes one endpoint and lets the client ask for exactly the fields it wants. GraphQL shines when clients need very different shapes of data and you want to avoid over-fetching or many round-trips — typically rich frontends. REST wins on simplicity, caching (HTTP caching is built in), and tooling, and is usually the right default for a straightforward resource API. The honest answer: REST unless you have the specific over-fetching / many-clients problem GraphQL solves.
What they're testing: that you don't pick GraphQL for hype — you justify it with a concrete fetching problem.
What is idempotency, and how do you make an unsafe endpoint safe to retry?
An operation is idempotent if doing it twice has the same effect as once. It matters because clients retry on timeouts, and a timeout doesn't tell you whether the first call succeeded — so a non-idempotent "create order" or "charge card" can run twice. The fix is an idempotency key: the client sends a unique ID in a header, the server records it, and a repeat with the same key returns the original result instead of acting again. Any state-changing POST that can be retried needs this.
What they're testing: that you design for retries and at-least-once delivery, not a perfect network.
How does HTTP caching work for an API?
Two mechanisms. Cache-Control headers tell clients and proxies how long a response may be reused (max-age), which is great for data that rarely changes. ETag plus If-None-Match does conditional requests: the server sends a version tag, the client sends it back, and the server replies 304 Not Modified with no body if nothing changed — saving bandwidth. Caching is one of REST's real advantages over RPC-style APIs, and it only works cleanly because GET is safe and idempotent.
What they're testing: that you can cut load with HTTP's own caching, and know it depends on safe methods.
How to actually answer these
The strongest API answers are short and mechanical: name the verb or status code, give the one rule (idempotency, statelessness, the breaking-change line), and stop. Resist listing every status code you know — the interviewer is checking judgement, not recall. If you're unsure of an exact code, reason from the family: "it's a client error, so 4xx, and since it's a validation failure specifically, 422."
Two habits that quietly raise your score: tie every choice to a property (why POST and not PUT? because create isn't idempotent), and mention statelessness unprompted when scaling comes up — it signals you've actually run an API in production. Prepping the whole backend stack? Pair this with the SQL, Python backend, and system design questions.
Rehearse these out loud, scored. Peakblick asks you REST API questions like these on a timer and scores every answer 1–10 with feedback — so you find the weak spots before the real interview. Free to try, no card.
Top comments (0)