REST API questions appear in almost every backend, full-stack, and even frontend engineering interview. Whether you are interviewing at an API-first company like Stripe or a startup building internal services, you need to understand REST principles deeply — not just at the definition level, but well enough to make real design decisions and defend trade-offs.

This guide covers 30 questions organized from basic to advanced. The basics section covers fundamental concepts you must know cold. The intermediate section covers practical concerns like authentication, versioning, and pagination. The advanced section covers system design topics that come up in senior-level interviews. For each question, we provide the answer plus the follow-up questions interviewers commonly ask.

30
Questions Covered
3
Difficulty Levels
2026
Updated For

Basics (Questions 1–10)

Q1 What is REST? What does it stand for?
REST stands for Representational State Transfer. It is an architectural style (not a protocol or standard) for designing networked applications. A RESTful API uses HTTP methods to perform operations on resources identified by URLs. The key constraints are: client-server separation, statelessness (each request contains all information needed), cacheability, a uniform interface, and a layered system architecture. REST was defined by Roy Fielding in his 2000 doctoral dissertation.
Q2 What are the main HTTP methods and when do you use each?
GET retrieves a resource (safe, idempotent). POST creates a new resource (not idempotent). PUT replaces an entire resource (idempotent). PATCH partially updates a resource (can be idempotent). DELETE removes a resource (idempotent). Follow-up: "What does idempotent mean?" It means calling the operation multiple times produces the same result as calling it once. PUT /users/1 with the same body always yields the same state. POST /users might create a new user each time.
Q3 What are the most important HTTP status codes?
2xx Success: 200 OK (general success), 201 Created (resource created via POST), 204 No Content (success with no body, common for DELETE). 3xx Redirect: 301 Moved Permanently, 304 Not Modified (caching). 4xx Client Error: 400 Bad Request (malformed input), 401 Unauthorized (no/invalid auth), 403 Forbidden (auth valid but not permitted), 404 Not Found, 409 Conflict (duplicate resource), 422 Unprocessable Entity (validation error), 429 Too Many Requests (rate limited). 5xx Server Error: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable.
Q4 What is the difference between PUT and PATCH?
PUT replaces the entire resource. If you PUT a user object with only a name field, all other fields are overwritten (potentially to null). PATCH updates only the specified fields, leaving everything else unchanged. In practice, most APIs use PATCH for updates because PUT's full-replacement semantics are rarely what clients want. Follow-up: "Is PATCH always idempotent?" Not necessarily — it depends on the implementation. A PATCH that says "increment counter by 1" is not idempotent, but a PATCH that says "set name to 'Alice'" is.
Q5 What does "stateless" mean in REST?
Each request from client to server must contain all the information needed to understand and process the request. The server does not store client context between requests. Authentication tokens, session data, and user preferences must be sent with every request (typically via headers). This enables horizontal scaling — any server can handle any request because there is no server-side session state to maintain. Follow-up: "How do you handle sessions then?" Use JWT tokens or session IDs that the client includes in every request header.
Q6 What is the difference between 401 and 403?
401 Unauthorized means the request lacks valid authentication credentials. The client needs to log in or provide a valid token. 403 Forbidden means the client is authenticated (we know who they are) but does not have permission to access the resource. Re-authenticating will not help — they simply do not have the required role or permission. Common mistake: using 403 for unauthenticated requests or 401 for authorization failures.
Q7 What makes a good REST API URL structure?
Use nouns (not verbs) for resources: /users not /getUsers. Use plural nouns: /users/123 not /user/123. Use hierarchy for relationships: /users/123/orders. Use query parameters for filtering: /users?role=admin&active=true. Keep URLs lowercase with hyphens: /order-items not /orderItems. Never expose implementation details: /users not /api/v1/mysql/users_table.
Q8 What is idempotency and why does it matter?
An operation is idempotent if calling it multiple times produces the same result as calling it once. GET, PUT, DELETE are idempotent. POST is not. Idempotency matters for reliability: if a network failure occurs and the client retries a request, idempotent operations are safe to retry without side effects. This is critical for payment APIs — you do not want to charge a customer twice because of a network timeout. APIs often use idempotency keys (a unique request ID sent by the client) to make POST requests idempotent.
Q9 What is HATEOAS?
HATEOAS (Hypermedia As The Engine Of Application State) is a REST constraint where responses include links to related resources and available actions. Instead of the client hardcoding URLs, the API response tells the client what it can do next. Example: a GET /orders/123 response might include links to /orders/123/cancel, /orders/123/items, and /orders/123/invoice. In practice, very few APIs implement full HATEOAS. It adds complexity and most teams find it unnecessary for internal or well-documented APIs.
Q10 What is the difference between query parameters and path parameters?
Path parameters identify a specific resource: /users/123 (user with ID 123). Query parameters filter, sort, or paginate a collection: /users?role=admin&sort=created_at. Rule of thumb: if the parameter identifies a resource, use a path parameter. If it modifies the response (filtering, pagination, sorting), use a query parameter.

Intermediate (Questions 11–20)

Q11 How should you handle API authentication?
User-facing APIs: OAuth 2.0 with JWT tokens. Use short-lived access tokens (15–60 min) with refresh tokens. Server-to-server: API keys with HMAC signatures. Internal microservices: mTLS (mutual TLS). Never send credentials in query parameters (they get logged). Always use HTTPS. Store secrets securely — never in code or version control. Follow-up: "What goes inside a JWT?" Three parts: header (algorithm, type), payload (claims: user ID, roles, expiry), signature (HMAC or RSA signed).
Q12 What is API versioning and what are the best approaches?
Versioning manages breaking changes without disrupting consumers. Three approaches: URL path (/v1/users) — simplest, most common, used by Stripe and Twilio. Header (Accept: application/vnd.api.v2+json) — cleaner URLs but harder to test. Query parameter (/users?version=2) — flexible but can confuse. Best practice: version at the URL level for public APIs, use header versioning for internal APIs where you control all clients. Never break existing versions — deprecate them with long sunset timelines.
Q13 How do you implement pagination?
Three common patterns: Offset-based (?page=3&per_page=20) — simple but slow for large offsets because the database still scans skipped rows. Cursor-based (?cursor=abc123&limit=20) — uses an opaque cursor (usually a base64-encoded ID) to fetch the next page. Consistent performance regardless of page depth. Keyset-based (?after_id=500&limit=20) — uses the last item's sort key to fetch the next page. Similar to cursor but transparent. For most APIs, cursor-based pagination is the best default — it handles concurrent inserts/deletes gracefully and performs well at any depth.
Q14 How do you implement rate limiting?
Common algorithms: Token Bucket (allows bursts up to a limit, then throttles), Sliding Window (counts requests in a rolling time window), Fixed Window (resets at fixed intervals). Use Redis for distributed rate limiting across servers. Communicate limits via headers: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset. Return 429 Too Many Requests when exceeded. Follow-up: "How do you rate limit per user vs. per IP?" Use the authenticated user ID when available, fall back to IP for unauthenticated requests. Consider different limits per plan tier.
Q15 What is CORS and how does it work?
CORS (Cross-Origin Resource Sharing) is a browser security mechanism that restricts web pages from making requests to a different origin (domain, protocol, or port). When a browser makes a cross-origin request, it first sends a preflight OPTIONS request to check if the server allows it. The server responds with headers like Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers. Common mistake: setting Access-Control-Allow-Origin: * in production — this allows any website to call your API. Whitelist specific origins instead.
Q16 How do you handle errors consistently in a REST API?
Use a standard error response format across all endpoints:
{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Email address is invalid",
    "details": [
      { "field": "email", "issue": "Must be a valid email" }
    ]
  }
}
Use appropriate HTTP status codes (do not return 200 for errors). Include a machine-readable error code, a human-readable message, and field-level details for validation errors. Never expose stack traces or internal details in production error responses.
Q17 What is content negotiation?
Content negotiation lets clients and servers agree on the format of the response. The client sends an Accept header (e.g., Accept: application/json) and the server responds with the appropriate format, setting the Content-Type header. If the server cannot produce the requested format, it returns 406 Not Acceptable. In practice, most modern APIs only support JSON, but content negotiation matters for APIs that need to support XML, CSV, or Protocol Buffers alongside JSON.
Q18 How do you design an API for bulk operations?
Three approaches: (1) Batch endpoint — accept an array of resources in a single POST: POST /users/bulk with an array body. Return individual status for each item. (2) Async processing — for large batches, return 202 Accepted with a job ID, then let the client poll GET /jobs/{id} for status. (3) Multipart request — each part is an independent request. Choose based on payload size and processing time. For anything over 100 items, use async processing.
Q19 How do you handle long-running operations in a REST API?
Return 202 Accepted immediately with a resource URL for the operation status. The client polls that URL until the operation completes. Response pattern:
POST /reports/generate → 202 Accepted
{ "status_url": "/operations/abc123" }

GET /operations/abc123 → 200 OK
{ "status": "processing", "progress": 45 }

GET /operations/abc123 → 200 OK
{ "status": "completed", "result_url": "/reports/xyz" }
Alternative: use webhooks to notify the client when the operation completes, eliminating the need for polling.
Q20 What is the difference between 200, 201, and 204?
200 OK is the general success response — use it for GET requests and most other successful operations that return data. 201 Created indicates a new resource was created — use it for successful POST requests and include a Location header pointing to the new resource. 204 No Content means success with no response body — use it for DELETE or PUT requests where you do not need to return the updated resource. Being precise with these codes makes your API self-documenting.

Advanced (Questions 21–30)

Q21 What is the difference between REST and GraphQL? When would you choose each?
REST uses fixed endpoints that return predefined data structures. GraphQL uses a single endpoint where clients specify exactly what data they need. REST is simpler for CRUD operations and benefits from HTTP caching. GraphQL excels when clients need flexible queries, when mobile apps need to minimize data transfer (no over-fetching), or when you have multiple frontend clients with different data needs. Trade-offs: GraphQL requires more server-side complexity (resolvers, schema management, query cost analysis). Many companies use both: REST for simple CRUD, GraphQL for complex queries. API-first companies like Stripe have built entire businesses on well-designed REST APIs.
Q22 How do you design API caching?
Multiple layers: HTTP caching with Cache-Control, ETag, and Last-Modified headers. Set Cache-Control: max-age=300 for responses that can be cached for 5 minutes. Use ETags for conditional requests — the client sends If-None-Match and gets 304 Not Modified if nothing changed. CDN caching for geographically distributed performance. Application caching with Redis/Memcached for expensive database queries. Never cache responses that contain user-specific data unless you are using Vary headers correctly. Follow-up: "How do you invalidate caches?" Use cache-busting with version parameters, short TTLs with background refresh, or event-driven invalidation.
Q23 What is an API gateway and what problems does it solve?
An API gateway is a single entry point that sits in front of your backend services. It handles: routing (directing requests to the correct service), authentication (validating tokens before requests reach services), rate limiting, request/response transformation, load balancing, monitoring and logging, and circuit breaking (preventing cascading failures). Common gateways: Kong, AWS API Gateway, Envoy. Trade-offs: it adds latency (one extra hop) and becomes a single point of failure that must be highly available.
Q24 How do you design webhook APIs?
Webhooks are HTTP callbacks that notify external systems when events occur. Design considerations: (1) Use HTTPS endpoints only. (2) Sign payloads with HMAC so recipients can verify authenticity. (3) Implement retry with exponential backoff for failed deliveries. (4) Include a unique event ID so recipients can deduplicate. (5) Log all deliveries and their responses. (6) Provide a webhook testing endpoint in your developer portal. (7) Set reasonable timeouts (5–10 seconds) — if the recipient takes longer, the delivery should be retried. (8) Allow consumers to filter which events they receive.
Q25 How do you handle API security beyond authentication?
Layered security: (1) Input validation — validate all inputs on the server, never trust the client. (2) SQL injection prevention — use parameterized queries, never string concatenation. (3) Rate limiting per user and per IP. (4) Request size limits to prevent payload abuse. (5) HTTPS everywhere — no exceptions. (6) CORS configuration with specific allowed origins. (7) Security headers (Content-Security-Policy, X-Content-Type-Options). (8) API key rotation with grace periods. (9) Audit logging for all write operations. (10) Dependency scanning for known vulnerabilities.
Q26 How do microservices communicate via REST APIs?
In a microservices architecture, services communicate via: Synchronous REST (service A calls service B's API directly) — simple but creates coupling and can cascade failures. Asynchronous messaging (service A publishes an event, service B consumes it) — more resilient but eventually consistent. Service mesh (sidecar proxy handles inter-service communication) — adds observability and security. Best practices for synchronous REST between services: use circuit breakers (fail fast if a downstream service is unhealthy), set aggressive timeouts, implement retries with jitter, and use bulkhead patterns to isolate failures.
Q27 How do you version and evolve an API without breaking clients?
Strategies: (1) Additive changes only — add new fields and endpoints without removing existing ones. This is the safest approach and avoids versioning entirely for most changes. (2) Deprecation headers — use Sunset and Deprecation headers to signal upcoming removals. (3) API versioning for breaking changes, with long overlap periods (12+ months). (4) Feature flags — roll out new behavior to opt-in clients before making it default. (5) Consumer-driven contract testing — each API consumer defines tests that the provider must pass, catching breaking changes in CI.
Q28 How do you design a search API?
Use query parameters for simple filtering: GET /products?category=electronics&min_price=50&sort=price:asc. For complex searches, consider a POST endpoint with a search body: POST /products/search with structured filter objects. Include pagination, sorting, and faceted results. Return metadata: total count, available filters, applied filters. For full-text search, consider Elasticsearch behind the API. Performance: cache popular queries, use database indexes on filterable fields, limit result sizes. Follow-up: "How do you handle typo tolerance?" Use fuzzy matching at the search engine level (Elasticsearch has built-in fuzziness), not at the API level.
Q29 What is eventual consistency and how does it affect API design?
Eventual consistency means that after a write, not all reads will immediately reflect the change — but they will converge eventually. This is common in distributed systems. API design implications: (1) A POST that creates a resource might not show up immediately in a GET listing. (2) Return the created resource directly in the POST response so the client has it immediately. (3) Use If-Match headers with ETags for optimistic concurrency control. (4) Communicate consistency expectations in your documentation. (5) Provide a "read-your-writes" guarantee where possible by routing reads to the same node that handled the write.
Q30 How would you design an API for real-time data?
REST is not ideal for real-time use cases, but here are the patterns: (1) Polling — client repeatedly calls GET at intervals. Simple but inefficient and creates unnecessary load. (2) Long polling — server holds the connection open until new data is available. Better than polling but still has overhead from repeated connections. (3) Server-Sent Events (SSE) — server pushes events over a single HTTP connection. Excellent for one-directional real-time updates (live dashboards, notifications). (4) WebSockets — full-duplex communication channel. Best for bidirectional real-time needs (chat, collaborative editing). Choose the simplest option that meets your latency requirements — SSE is often sufficient and simpler than WebSockets.
Interview Tip "When answering API design questions, always lead with the trade-offs. There is rarely a single 'correct' answer — interviewers want to see that you can reason about the pros and cons of different approaches and choose based on specific constraints."

For more technical interview preparation, see our system design interview guide, our data analyst interview questions, and the evolution of technical interviews. Companies like Stripe and Vercel are known for their API-first engineering cultures — check their interview prep guides for company-specific preparation.

Frequently Asked Questions

What are the main HTTP methods used in REST APIs?+
The five main methods are GET (retrieve), POST (create), PUT (replace), PATCH (partial update), and DELETE (remove). GET and DELETE have no request body. PUT is idempotent while POST is not.
What is the difference between REST and GraphQL?+
REST uses fixed endpoints with predefined responses. GraphQL uses a single endpoint where clients specify exactly what data they need. REST is simpler and benefits from HTTP caching. GraphQL excels for flexible queries and minimizing data transfer. Many companies use both.
How do you implement API rate limiting?+
Common algorithms include Token Bucket, Sliding Window, and Fixed Window. Use Redis for distributed rate limiting. Communicate limits via X-RateLimit headers and return 429 Too Many Requests when exceeded.
What is API versioning and what are the best approaches?+
Three approaches: URL path versioning (/v1/users) is simplest and most common. Header versioning is cleaner but harder to test. Query parameter versioning is flexible but confusing. Most major APIs use URL path versioning.
How should you handle API authentication?+
User-facing APIs: OAuth 2.0 with JWT tokens. Server-to-server: API keys with HMAC signatures. Internal microservices: mTLS. Always use HTTPS. Never send credentials in query parameters.

Find engineering roles at API-first companies

Browse backend and full-stack roles with culture context at companies that build world-class APIs.

Browse Engineering Jobs → Culture Interview Questions Tool →