REST API Interview Questions and Answers for 2026

Most backend interviews open with REST because it's the language almost every API speaks. The questions sound simple, but they probe whether you actually understand HTTP, not just whether you've called fetch a few times. The fastest way to fail is to confuse "safe" with "idempotent," or to claim PUT and PATCH do the same thing.

Here are 16 of the most common REST API interview questions and answers, grouped by what interviewers are really testing: REST fundamentals, HTTP mechanics, design decisions, and security. Each answer is short enough to say out loud in an interview and precise enough to survive a follow-up.

REST fundamentals

1. What is REST?

REST (Representational State Transfer) is an architectural style for networked applications, defined by Roy Fielding in his 2000 dissertation. It isn't a protocol or a standard — it's a set of constraints applied on top of HTTP. An API that follows those constraints is called *RESTful*. The core idea: everything is a resource (a user, an order, a document), each resource has a unique URI, and you act on it using standard HTTP methods. The Wikipedia entry on REST summarizes the six constraints clearly.

2. What are the main constraints of REST?

There are six, and you should be able to name at least four:

• Client-server — separate the UI from data storage so each can evolve independently.
• Stateless — every request carries all the context the server needs.
• Cacheable — responses must declare whether they can be cached.
• Uniform interface — resources are identified by URIs and manipulated through standard methods.
• Layered system — a client can't tell whether it's talking to the origin server or a proxy.
• Code on demand (optional) — the server can send executable code, like JavaScript.

3. What does "stateless" actually mean?

The server stores no client session state between requests. Each request must carry everything needed to process it — credentials, identifiers, parameters. Any server behind a load balancer can then answer any request without shared session memory, which is what lets REST APIs scale horizontally. Note that *application state* (data in a database) is fine; it's *session state* that REST forbids on the server.

4. What is a resource, and how should you name endpoints?

A resource is any thing the API exposes. Endpoints should use nouns, not verbs, and rely on HTTP methods for the action. Use GET /users/42 and DELETE /users/42, not GET /getUser?id=42 or POST /deleteUser. Collections are plural (/orders), and nesting shows relationships (/users/42/orders). If you're prepping for broader architecture rounds too, our system design interview questions guide covers how resource modeling fits into larger services.

HTTP methods, idempotency, and status codes

5. What are the main HTTP methods and what do they do?

This is where interviewers separate people who memorized CRUD from people who understand the semantics. The two properties that matter are safe (doesn't change server state) and idempotent (making the same request N times has the same effect as making it once). The MDN documentation on HTTP request methods is the authoritative reference here.

6. What's the difference between safe and idempotent?

A safe method never modifies the resource — GET and HEAD only read. An idempotent method can modify state, but repeating it produces the same final result. Every safe method is idempotent, but the reverse isn't true: DELETE is idempotent (deleting the same record twice leaves it deleted) yet not safe (it changes state). The formal definitions live in RFC 9110, the core HTTP semantics specification.

7. PUT vs PATCH — what's the real difference?

PUT replaces the entire resource with the payload you send; any field you omit gets wiped or reset. PATCH applies a partial update, touching only the fields you include. That's also why PUT is idempotent and PATCH usually isn't — a PATCH like "increment counter by 1" produces a different result each time it runs.

8. What HTTP status codes should a REST API return?

Use the right class for the situation, not 200 for everything. The full list is documented in the MDN HTTP status code reference.

• 2xx success — 200 OK, 201 Created (after a POST), 204 No Content (after a successful DELETE).
• 3xx redirection — 301 Moved Permanently, 304 Not Modified (caching).
• 4xx client error — 400 Bad Request, 401 Unauthorized (not authenticated), 403 Forbidden (authenticated but not allowed), 404 Not Found, 429 Too Many Requests.
• 5xx server error — 500 Internal Server Error, 503 Service Unavailable.

The 401 vs 403 distinction is a frequent follow-up: 401 means "we don't know who you are," 403 means "we know, and you still can't."

9. How should a REST API handle errors?

Return the correct status code, then a structured body the client can parse — a stable error code, a human-readable message, and a details field for field-level validation problems. Don't return 200 OK with {"error": "..."} in the body; that breaks every client that trusts the status line. Keep the error format consistent across every endpoint.

API design decisions

10. How do you handle versioning?

The three common approaches: URI versioning (/v1/users) — most visible and easy to route; header versioning (Accept: application/vnd.api.v2+json) — keeps URLs clean; and query-parameter versioning (/users?version=2) — simplest but messy to cache. URI versioning is the most common in practice because it's obvious and cache-friendly. The key principle: never make a breaking change to an existing version.

11. How do you paginate large collections?

• Offset/limit (?offset=40&limit=20) — easy, but slow on large tables and unstable if rows are inserted mid-scroll.
• Cursor-based (?cursor=abc123) — pass an opaque pointer to the last item; stable and efficient for big datasets.
• Page-based (?page=3&size=20) — human-friendly for UIs.

Cursor pagination is what high-traffic APIs use because it doesn't drift when data changes underneath you.

12. REST vs GraphQL vs SOAP — when would you choose each?

A classic comparison question. GraphQL was created by Facebook to fix REST's over-fetching and under-fetching, while SOAP is an older, heavier XML protocol still common in banking and enterprise systems.

Short answer for an interview: REST for most public APIs and simple resource access, GraphQL when clients need flexible nested queries and you want to avoid round trips, SOAP when you're in a regulated enterprise stack that requires it.

13. What is HATEOAS?

Hypermedia As The Engine Of Application State — the constraint that responses include links telling the client what it can do next. A GET /orders/42 might return links to cancel or pay. It's the highest level of REST maturity and the least implemented in practice, but interviewers ask it to see whether you've read past the CRUD basics.

Security and authentication

14. How do you secure a REST API?

Always serve over HTTPS. Authenticate with tokens rather than sessions (REST is stateless), validate every input on the server, apply rate limiting to blunt abuse, and enforce authorization on every endpoint — never trust the client to hide a button. The two dominant token mechanisms are OAuth 2.0 and JWT.

15. What's the difference between OAuth and JWT?

They solve different problems and are often used together. OAuth 2.0 is an authorization framework — it defines how a client gets permission to access resources on a user's behalf, typically returning an access token. A JSON Web Token (JWT) is a token format — a signed, self-contained JSON object carrying claims (who the user is, when it expires). OAuth often issues JWTs as its access tokens, but you can use JWTs without OAuth, and OAuth tokens don't have to be JWTs. If your interview leans cloud-native, our AWS interview questions guide covers how these tokens flow through managed services.

16. Why is statelessness good for authentication?

Because the server stores no session, a self-contained token like a JWT lets any server in a cluster validate a request just by checking the signature — no shared session store, no sticky sessions. That's the same property that makes REST scale, applied to auth. The trade-off: you can't easily revoke a JWT before it expires, so short lifetimes plus refresh tokens are standard.

FAQ

What are the most common REST API interview questions?

Expect questions on the six REST constraints, the difference between safe and idempotent methods, PUT vs PATCH, common HTTP status codes (especially 401 vs 403), statelessness, versioning and pagination strategies, REST vs GraphQL, and how OAuth and JWT secure an API.

Is REST a protocol or an architecture?

REST is an architectural style, not a protocol. It defines constraints — statelessness, a uniform interface, cacheability — that are usually layered on top of the HTTP protocol. HTTP is the protocol; REST is the design pattern that uses it.

What's the difference between PUT and POST?

POST creates a new resource and is neither safe nor idempotent — calling it twice creates two records. PUT replaces a resource at a known URI and is idempotent — calling it twice leaves the same single result. Use POST to create, PUT to replace.

Are all idempotent methods also safe?

No. Safe methods (GET, HEAD) never change server state and are always idempotent. But idempotent methods like PUT and DELETE do change state — they're just repeatable without additional effect. So every safe method is idempotent, but not every idempotent method is safe.

How should I prepare for a REST API interview?

Practice explaining each concept out loud in two or three sentences, since interviews test clarity under pressure. Pair theory with the official specs and rehearse the common comparison questions — PUT vs PATCH, REST vs GraphQL, OAuth vs JWT — until they're automatic.

Land the interview, not just the answers

Knowing every status code cold still won't help if your resume never reaches a human. The fastest path into a backend role is usually a 15-minute conversation with the engineer or manager doing the hiring — not the apply button. Articuler helps jobseekers find the actual hiring manager behind a posting using semantic search across 980M+ profiles, build a Playbook on what that person cares about, and send a personalized note that gets roughly 8x the reply rate of a generic message. Pair it with our technical interview questions guide and you'll walk in prepared for both the conversation and the whiteboard.