Top 50 REST API Interview Questions (2026)

A REST API is an interface that lets a client and server exchange data over HTTP following the REST style. It models data as resources, each with its own URL, and uses HTTP methods to act on them: GET to read, POST to create, PUT or PATCH to update, DELETE to remove.

REST stands for Representational State Transfer. The client asks for a resource, the server returns a representation of it (usually JSON) plus a status code, and no session is held between requests. It's the most common style for web and mobile APIs because it's simple, uses plain HTTP, and works with any client.

REST is the architectural style: the set of constraints Roy Fielding defined. RESTful is just the adjective for an API that follows those constraints. Saying an API is 'RESTful' means it obeys REST's rules like statelessness, a uniform interface, and resource-based URLs.

In everyday use people treat them as the same thing, and that's fine. If pushed, the honest note is that many APIs called RESTful only follow some constraints (they skip HATEOAS, for example), so 'RESTful' in practice is a spectrum, not a strict pass or fail.

The core methods map to CRUD: GET reads a resource, POST creates one, PUT replaces one, PATCH updates part of one, and DELETE removes one. GET is safe and doesn't change anything; the others change server state (except a well-designed PATCH or PUT that lands on the same result).

Two more come up: HEAD is like GET but returns only headers, no body, handy for checks; OPTIONS reports which methods a resource supports and drives CORS preflight. Knowing which method fits which action is the everyday core of REST design.

GET retrieves data and shouldn't change anything on the server. Its parameters go in the URL and query string, it can be cached and bookmarked, and repeating it is safe. Because the data sits in the URL, GET isn't for sensitive input.

POST sends data in the request body to create a resource or trigger an action. It changes server state, isn't cached by default, and repeating it can create duplicates, which is why forms warn you before resubmitting. Use GET to read, POST to create or submit.

A resource is any thing your API exposes: a user, an order, a product. Each resource has a URL that identifies it, and REST design uses nouns, not verbs, for those URLs. So it's /users and /users/42, not /getUser or /createUser, because the HTTP method already says what you're doing.

Collections are plural nouns (/users), a single item nests under it (/users/42), and sub-resources chain (/users/42/orders). The method carries the verb: GET /users/42 reads, DELETE /users/42 removes. Consistent, noun-based, hierarchical URLs are what make an API feel RESTful.

Status codes come in five families keyed by the first digit. 1xx is informational, 2xx means success, 3xx means redirection, 4xx means the client made an error, and 5xx means the server failed. Knowing the family tells you at a glance who's at fault and what to do.

The distinction that matters most in interviews is 4xx versus 5xx: a 404 or 400 means fix the request, while a 500 means the server broke and the client can retry later. Getting that split right is the base of good API error handling.

Read them off the action: 200 for a successful GET or update with a body, 201 when you create a resource (with a Location header to it), 204 for a success with nothing to return like a DELETE. On errors, 400 for a malformed request, 401 when auth is missing, 403 when auth is present but not allowed, 404 when the resource doesn't exist.

A few more separate strong candidates: 409 for a conflict like a duplicate, 422 when the body parses but fails validation, 429 when the client is rate-limited, and 500 for an unexpected server error. Returning the right code, not 200 with an error message inside, is what makes an API usable.

All three mean success, but they differ in what happened and what comes back. 200 OK is the general success with a response body, used for a GET or an update that returns the changed resource. 201 Created means a new resource was made, typically after a POST, and usually includes a Location header pointing to the new resource.

204 No Content means the request succeeded but there's nothing to send back, which fits a DELETE or an update where you don't return the body. Picking 201 for creates and 204 for empty-body successes, instead of 200 for everything, is a small detail that signals care.

401 Unauthorized means you're not authenticated: the server doesn't know who you are, so you need to send valid credentials. Despite the name 'Unauthorized', it's really about authentication being missing or invalid, like a missing or expired token, rather than about permissions on a resource.

403 Forbidden means you are authenticated but not allowed: the server knows who you are and is refusing this action, like a regular user hitting an admin-only endpoint. The quick rule is 401 = who are you, 403 = you can't do that.

JSON (JavaScript Object Notation) is a lightweight text format of key-value pairs and arrays that's easy for both humans and machines to read. It's smaller and simpler than XML, maps cleanly to objects in almost every language, and is native to JavaScript, which made it the default for web and mobile APIs.

REST doesn't require JSON, the style is format-agnostic, but JSON won on ergonomics. The client sends and receives JSON, sets Content-Type: application/json, and both sides parse it with built-in tools. XML still appears in older or enterprise APIs, but JSON is the everyday choice.

A request has a method and URL (GET /users/42), headers (metadata like Content-Type, Authorization, Accept), and an optional body carrying data for POST, PUT, or PATCH. Together they tell the server what you want, in what format, and who you are.

A response has a status code (200, 404), headers (Content-Type, caching, rate-limit info), and a body with the representation, usually JSON. Reading both sides fluently, especially headers, is what lets you debug an API instead of guessing.

Headers are key-value metadata sent alongside the body on both requests and responses. They describe the request or response without being part of the data itself: what format the body is in, who's calling, and how the response can be cached. The client and server both read them to decide how to handle a message.

The ones you'll name in most interviews: Content-Type (the format of the body being sent), Accept (the format the client wants back), Authorization (credentials, often a bearer token), and caching headers like Cache-Control and ETag. Knowing Content-Type versus Accept, request-side versus what-you-want-back, is a common quick check.

Path parameters identify a specific resource and live in the URL path: /users/42, where 42 is the path param. Query parameters filter, sort, or paginate a collection and come after the ?: /users?role=admin&page=2. They're optional modifiers on a request, not the resource identity.

Body parameters carry the payload for methods that send data (POST, PUT, PATCH), usually as JSON. The rule of thumb: path for which resource, query for how to filter or shape the result, body for the data you're sending. Putting a filter in the path or an ID in the body is a common design smell.

An operation is idempotent if making the same request many times leaves the server in the same end state as making it once. GET, PUT, and DELETE are idempotent: reading twice changes nothing, replacing a resource twice lands on the same result, deleting twice leaves it gone.

POST is not idempotent: two identical POSTs usually create two resources. This matters because networks retry: if a client resends a request after a timeout, an idempotent method is safe to retry, while a naive POST can double-charge or duplicate. It's a core concept interviewers return to.

A safe method doesn't change server state: it only reads. GET, HEAD, and OPTIONS are safe. Calling them has no side effects, so caches, search-engine crawlers, and browser prefetchers can call them freely without altering data. That guarantee is what makes those methods safe to automate.

It matters because tools rely on it. A search engine or a browser prefetch will happily send GET requests, and if a GET secretly deleted or modified data, that automation would cause chaos. So a link should never trigger a state change; that belongs behind POST, PUT, PATCH, or DELETE.

CRUD is Create, Read, Update, Delete, the four basic data operations, and REST maps HTTP methods onto them. Create is POST, Read is GET, Update is PUT (full) or PATCH (partial), and Delete is DELETE. So a resource like /users supports the whole lifecycle through standard methods.

The mapping isn't perfectly one-to-one, some actions don't fit CRUD neatly, but it's the mental model most APIs start from. When an interviewer asks you to design endpoints, walking the CRUD table for each resource is a clean, fast way to structure the answer.

An API (Application Programming Interface) is any contract that lets two pieces of software talk: a set of rules for requests and responses. That's a broad term covering library functions, SOAP services, GraphQL, gRPC, and more. A REST API is one specific kind of web API that follows REST's constraints over HTTP.

So every REST API is an API, but not every API is REST. When someone says 'the API', in a web context they usually mean a REST API, but naming REST as one style among several (alongside GraphQL and gRPC) shows you understand the wider category.

An endpoint is a specific URL where a resource or action lives, combined with the HTTP method you use on it. GET /users/42 and DELETE /users/42 hit the same URL but are two different endpoints because the method differs. Each endpoint does one thing: read a user, delete a user, list orders.

The base URL plus the path plus the method together define an endpoint. When designing an API you're really deciding your set of endpoints: which resources exist, which methods each supports, and what they return. Clear, consistent endpoints are what make an API easy to consume.

Statelessness means the server keeps no client session between requests. Every request carries all the context the server needs, credentials, IDs, parameters, so the server doesn't remember anything about you from the last call. There's no server-side session tied to a specific client.

It matters for scaling and reliability: because no request depends on server memory, any instance behind a load balancer can handle any request, and you can add or remove servers freely. The trade-off is the client resends context each time (a token on every request), which is a deliberate cost for horizontal scaling.

Use PUT when you're replacing the whole resource: the client sends the complete new representation, and the server overwrites everything. Use PATCH when you're changing only some fields and want to leave the rest as they are. Sending a partial body with PUT is a classic bug, because a strict PUT treats missing fields as 'clear them'.

The gotcha is idempotency: PUT is idempotent (replacing twice with the same body is the same result), but PATCH may not be, depending on the operation (an 'increment' PATCH isn't). Also, PATCH has more than one format (JSON Merge Patch vs JSON Patch), so agreeing on the format matters.

The three common approaches are URL versioning (/v1/users), header versioning (a custom Accept or version header), and query-param versioning (?version=1). URL versioning is the most visible and simplest to route and cache, which is why most public APIs use it despite purists preferring header-based.

Whatever you choose, the point is the same: let existing clients keep working when you make a breaking change by shipping the change under a new version. The real skill is minimizing breaking changes in the first place, adding fields is backwards-compatible, removing or renaming them isn't, so many changes never need a new version.

The two main strategies are offset-based (?page=2&limit=20 or ?offset=40&limit=20) and cursor-based (?limit=20&cursor=abc123). Offset is simple and lets users jump to any page, but it gets slow on huge tables and can skip or repeat rows when data changes between requests.

Cursor-based pagination passes a pointer to the last item seen and asks for the next batch. It's stable under inserts and deletes and stays fast at scale, which is why large APIs prefer it, but you can't jump to an arbitrary page. Pick offset for small admin lists, cursor for large or fast-changing feeds.

REST leans on HTTP caching. GET responses can be cached, and headers control it: Cache-Control sets how long and where a response can be stored, ETag gives a response a version tag, and Last-Modified gives a timestamp. On the next request the client sends If-None-Match with the ETag, and the server answers 304 Not Modified if nothing changed, saving bandwidth.

This is why REST's safe, cacheable GETs are an advantage: a CDN or browser can serve repeat reads without hitting your server. The care needed is invalidation, setting the right freshness and busting caches when data changes, so clients don't serve stale results.

Because REST is stateless, credentials travel on each request rather than in a server session. Common options: API keys for server-to-server or simple cases, bearer tokens (often JWTs) sent in the Authorization header for user auth, and OAuth 2.0 when a third party needs delegated access without the user's password.

A JWT carries claims (who the user is, what they can do) signed by the server, so any instance can verify it without a lookup, which fits statelessness well. The trade-offs to know: JWTs are hard to revoke before they expire, so keep them short-lived and pair them with refresh tokens.

Authentication is verifying who you are: checking a token or credentials to establish identity. Authorization is deciding what you're allowed to do once identified: whether this user can read, edit, or delete a given resource. Auth-n comes first, then auth-z.

In status-code terms this maps directly: a failed authentication is 401 (we don't know who you are), and a failed authorization is 403 (we know you, but you can't do this). Keeping the two ideas separate is what lets you design permissions cleanly.

Rate limiting caps how many requests a client can make in a window (say 100 per minute) to protect the API from abuse, runaway clients, and cost spikes. When a client exceeds the limit, the server returns 429 Too Many Requests instead of processing the call.

Good APIs signal the limits so clients can adapt: headers like X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset tell the client its budget, and a Retry-After header on a 429 says how long to wait. Common algorithms are token bucket and sliding window; naming one shows depth.

CORS (Cross-Origin Resource Sharing) is the mechanism that lets a browser call an API on a different origin (domain, protocol, or port) than the page it's running on. By default the same-origin policy blocks those calls; the server opts in by sending Access-Control-Allow-Origin and related headers.

For non-simple requests the browser first sends an OPTIONS preflight asking whether the real request is allowed, and only proceeds if the server approves. The key point interviewers check: CORS is a browser security feature enforced by the browser, not by your server-to-server calls, and it's the server's response headers that grant access.

Return the right status code and a consistent, structured body so clients can handle failures programmatically. A good error response has a machine-readable code, a human-readable message, and often a field pointing at what was wrong, all in the same shape every time so clients don't parse each error differently.

The anti-patterns to avoid: returning 200 with an error inside, leaking stack traces or internal details to the client, and using a different error shape per endpoint. Many teams adopt the Problem Details format (RFC 9457) for a standard JSON error structure.

Content negotiation is how a client and server agree on the format of a response. The client sends an Accept header saying what it wants (application/json, application/xml), and the server responds in the best format it supports, setting Content-Type to what it actually sent.

It lets one endpoint serve multiple formats, or multiple languages via Accept-Language, without separate URLs. In practice most JSON APIs only speak JSON, so negotiation is light, but knowing the Accept/Content-Type handshake explains how the same resource can be represented differently.

HATEOAS (Hypermedia As The Engine Of Application State) is the REST constraint where responses include links to the actions a client can take next, so the client discovers what's possible by following links instead of hardcoding URLs. A user response might include links to update it, delete it, or fetch its orders.

It's the least-followed REST constraint. Most APIs called RESTful skip it because it adds complexity and few clients actually use the links. Being honest that HATEOAS is part of 'true REST' but rare in practice is a better answer than pretending every API does it.

Over-fetching is when an endpoint returns more data than the client needs, wasting bandwidth: you call /users/42 and get fifty fields to show a name. Under-fetching is the opposite, when one call isn't enough and the client must make several round trips to assemble what it needs, like fetching a user, then their orders, then each order's items.

These are the classic REST pain points, and they're the main reason GraphQL exists, since it lets the client request exactly the fields and relations it wants in one query. In REST you soften them with sparse fieldsets (?fields=name,email), embedding related resources, and well-designed endpoints.

REST fits public APIs, simple CRUD, and cases where HTTP caching matters, since each resource has its own cacheable URL and any HTTP client can call it. It shines when the data needs are predictable and you want the operational simplicity of standard methods and status codes.

GraphQL fits clients with varied, nested data needs, mobile apps that want to avoid over-fetching, and product teams iterating fast on the shape of data, because the client asks for exactly the fields it wants in one request. The costs: caching is harder, and you must guard against expensive deep queries. Pick REST for simplicity and caching, GraphQL for flexible client-driven queries.

It's a way to grade how RESTful an API is, in four levels. Level 0 is a single endpoint doing everything (RPC over HTTP). Level 1 introduces separate resources with their own URLs. Level 2 uses HTTP methods and status codes correctly, which is where most real REST APIs sit. Level 3 adds HATEOAS, hypermedia links driving the client.

The model is useful as a checklist and a shared vocabulary: when someone says an API is 'Level 2', you know it uses proper resources, methods, and codes but not hypermedia. It's not a strict standard to chase to Level 3, but it frames what 'more RESTful' actually means.

Put all of it in query parameters on the collection endpoint, since these shape how you read a list without changing the resource itself. Filtering uses field params (/products?category=books&in_stock=true), sorting uses a sort param with a direction (/products?sort=-price for descending), and search uses a query param (/products?q=laptop). Keep the names consistent across endpoints so clients learn the pattern once.

The design calls to make: decide which fields are filterable to avoid unbounded queries, define how you express ranges (price_min, price_max) and multiple values, and combine filtering with pagination cleanly. Documenting the allowed params matters, because an open-ended filter that hits any column is both a performance and a security risk.

Clarify first: who are the clients, what's the scale, is auth needed, and are there compliance limits. Then model resources as nouns: /posts, /posts/{id}, /posts/{id}/comments, /users/{id}, /tags. Map methods onto CRUD: GET to list and read, POST to create, PATCH to edit, DELETE to remove, each returning the right status code (201 with a Location on create, 204 on delete).

Then layer the cross-cutting concerns: cursor pagination and filtering on the collections (/posts?tag=rest&limit=20), versioning (/v1/), auth via bearer tokens with role-based checks (401 vs 403), rate limiting with 429, consistent structured errors, and caching headers on reads. The structure that scores is clarify, model resources, map methods and codes, then pagination, auth, versioning, errors, each justified by the requirements you asked for.

POST isn't idempotent by default, so a client that retries after a timeout can create a duplicate (charge a card twice, place two orders). The fix is an idempotency key: the client generates a unique key and sends it in a header on the request, and the server records the result for that key.

If the same key arrives again, the server returns the stored result instead of doing the work a second time, so the retry is safe. You store keys with a TTL and scope them per operation. Payment APIs like Stripe popularized this exact pattern, and naming it signals you've built reliable write paths.

the basics that catch most issues: HTTPS everywhere so tokens and data aren't sent in the clear, authentication on every non-public endpoint, and authorization checks on each resource so a user can't read or edit another's data (broken object-level authorization is a top API vulnerability) comes first. Validate and sanitize all input to block injection.

Then add depth: rate limiting to stop abuse, least-privilege scopes on tokens, no sensitive data in URLs (they get logged), strict CORS, and security headers. Return generic errors that don't leak internals, and log with a correlation ID. The OWASP API Security Top 10 is the checklist to name, with broken authorization and excessive data exposure being the most common real failures.

PUT should replace a resource so that applying the same body twice lands on the same state. It breaks when the server does something non-deterministic on each call: setting updated_at to now, auto-incrementing a version on every write, or appending to a list instead of replacing it. Now two identical PUTs produce different results.

It also breaks with race conditions: two clients PUT different bodies and the last write wins silently, losing an update. The fixes are conditional requests with If-Match and an ETag (reject the write if the resource changed since the client read it) and keeping side effects deterministic. Optimistic concurrency is the pattern to name.

Don't block the request until the work finishes. Accept the request and return 202 Accepted immediately with a URL to a status resource, then do the work in the background. The client polls that status URL (or you notify it via a webhook) until it reports done, at which point the status resource links to the finished result.

This keeps the API responsive, avoids client timeouts on slow work, and lets you retry the job independently. The pattern is: POST to start, 202 plus a Location to /jobs/{id}, GET /jobs/{id} returns pending or completed, and the completed response points at the result. Webhooks replace polling when the client can receive callbacks.

REST's one-resource-per-request model is awkward for bulk work, so you extend it deliberately. Common approaches: accept an array in a POST to a batch endpoint (POST /users/batch with a list), or expose an action endpoint (POST /orders/bulk-cancel). Return a per-item result so the client knows which succeeded and which failed, since a batch can partially succeed.

The design decisions are: is the batch all-or-nothing (transactional) or best-effort per item, and what status code fits a partial success (often 207 Multi-Status, or 200 with a per-item results array). Being explicit about partial failure is what separates a usable bulk API from one that hides which items failed.

Caching cuts latency and load: a CDN or client serves repeat GETs without touching your origin, and conditional requests with ETags save bandwidth even on revalidation. For read-heavy APIs this is one of REST's biggest strengths, since safe GETs are cacheable by design.

The cost is staleness and invalidation. Longer max-age means faster responses but a bigger window where clients see old data, and busting caches across a CDN when data changes is genuinely hard. You tune per resource: long TTLs for rarely-changing reference data, short or no caching for volatile or user-specific data, and ETags where you want freshness checks without full re-downloads.

Polling means the client repeatedly calls an endpoint asking 'has anything changed', which wastes requests when nothing has and adds latency when something has. It's simple and works everywhere because the client drives it, but it scales badly under many clients and always lags behind real events by the poll interval.

Webhooks flip it: the server calls a client-provided URL when an event happens, so the client learns immediately and makes no wasted calls. Use webhooks for event-driven needs (a payment cleared, a job finished) where the client can receive HTTP. The costs to name: you must secure webhooks (signature verification), handle retries and duplicates (so consumers must be idempotent), and give clients a way to catch up if they miss one.

For it: hypermedia decouples clients from hardcoded URLs, so the server can move or rename endpoints and evolve the API without breaking clients that just follow links. It makes the API self-describing and discoverable, which is the original vision of REST.

Against it: almost no clients actually consume the links; they read the docs and hardcode paths anyway, so the extra payload and server complexity buy little. That's why the vast majority of APIs stop at Richardson Level 2. The honest senior take is that HATEOAS is theoretically nice but rarely pays off, and you'd only invest in it for a long-lived public API with many independent clients.

The N+1 problem is when a client fetches a list (one request) and then makes one request per item to get related data (N more), turning a screen into dozens of round trips. In REST it comes from strictly separating resources without a way to fetch related data together.

Fixes: support embedding or expansion (GET /posts?expand=author returns each post with its author inline), offer sparse fieldsets to keep the expanded payload lean, or add a purpose-built endpoint that returns the composed view a screen needs. On the server side, batch the underlying database queries so one API call doesn't fan out into N queries either. If clients constantly compose data, that's often the signal that GraphQL fits better.

Track the signals that reflect user experience: request rate, error rate (especially the 5xx and 4xx split), and latency percentiles (p50, p95, p99, not just the average, because tail latency is what users feel). Break these down per endpoint so a slow route doesn't hide inside an overall-healthy average.

Add distributed tracing with a correlation ID propagated across services so you can follow one request end to end, structured logs tied to that ID, and alerts on symptoms like a rising error rate or p99 latency rather than raw CPU. Health and readiness endpoints let orchestrators route traffic only to instances that can serve. The goal is to detect and localize a problem fast, not just know 'the API is down'.

Favor additive, backwards-compatible changes: adding a new optional field, a new endpoint, or a new optional parameter doesn't break clients that ignore it. What breaks clients is removing or renaming fields, changing a field's type, making an optional field required, or changing status-code behavior, so treat those as breaking and defer them.

When a breaking change is unavoidable, ship it under a new version and run the old version in parallel with a deprecation window: announce it, add a Deprecation or Sunset header, monitor who's still calling the old version, and give clients time to migrate. The discipline of 'additive by default, versioned only when forced' is what keeps integrations alive.

gRPC uses HTTP/2 and binary Protocol Buffers, giving low latency, small payloads, streaming, and a strongly-typed contract generated into client and server code. That makes it a strong fit for internal service-to-service communication in a microservices system where performance and a shared schema matter.

REST wins for public-facing APIs, browser clients (gRPC needs a proxy like grpc-web to reach browsers), and anywhere human-readable JSON and standard HTTP tooling help. The typical split: gRPC between your backend services, REST at the edge that external clients and browsers hit. Naming that boundary is the mature answer.

The failure to prevent is the lost update: two clients read a resource, both edit it, and the second write silently overwrites the first. The standard fix is optimistic concurrency control: give each resource a version (an ETag or version field) and require the client to send it back with the update. If the stored version differs, the resource changed since they read it, so you reject the write.

In status-code terms, a stale version means you return 409 Conflict or 412 Precondition Failed. This is optimistic because it assumes conflicts are rare and only checks at write time, which scales better than pessimistic locking that holds a lock across the whole edit. Pessimistic locking fits when conflicts are frequent and expensive to redo, but it hurts throughput. For most REST APIs, ETag-based optimistic concurrency is the right default.

REST defines six constraints: client-server separation, statelessness, cacheability, a uniform interface, a layered system, and optional code-on-demand. Most well-built APIs honor client-server, statelessness, cacheability, and layered systems, since those four are what give REST the horizontal scaling and operational simplicity it's known for in production.

The uniform interface is partly followed (proper methods, status codes, resource URLs) but its HATEOAS part is usually skipped, and code-on-demand (sending executable code to the client) is rare. So in practice a typical 'RESTful' API satisfies most constraints but not hypermedia. Knowing which are load-bearing (statelessness, cacheability) versus commonly dropped (HATEOAS) is the depth here.

A hard delete removes the row for good, which is clean but loses history and can break references from other records. When data needs to be recoverable, auditable, or referenced after removal, you soft-delete instead: mark the resource as deleted (a deleted_at timestamp or a status flag) and filter it out of normal reads, so DELETE /users/42 hides the user rather than erasing it.

The design decisions are: does DELETE do a soft or hard delete by default, how do you expose recovery (a restore action, or an admin view of deleted items), and how do you eventually purge for real, since regulations like a right-to-erasure request may require a genuine hard delete. Being explicit about which semantics your DELETE has, and why, is what this question checks.