What is a REST API and what are its main principles?

Start by defining REST as an architectural style for networked applications that uses stateless communication over HTTP and resource-based URIs. Explain the key constraints you would mention, such as client-server separation, statelessness, cacheability, uniform interface, layered system, and optional code on demand. Give a concrete example, for instance a simple resource like /users/{id} where GET retrieves a user and POST creates one, and show how responses use standard HTTP status codes and JSON bodies. Describe how these principles help with scalability and clear client-server responsibilities in real projects you have worked on. Tip the interviewer toward trade-offs by saying when you would relax a constraint, for example allowing some state for performance, and avoid claiming REST is a strict protocol rather than a set of conventions. Do not confuse REST with any single library or tool, focus on the concepts and how you applied them.

Can you explain common HTTP methods and when to use each?

Answer by mapping methods to CRUD: GET for read, POST for create, PUT for full replace, PATCH for partial update, and DELETE for remove. Mention when you would return 201 Created for POST and 204 No Content for successful deletes or updates without a response body. Give a specific example, such as using PUT to replace an entire user profile at /users/{id} and PATCH to change only the email field, and describe idempotency differences between them. Explain that GET must not change server state, and using POST for non-idempotent actions like search histories is common. Warn against misusing methods, for example using GET to trigger state changes, and mention you should document expected behavior so clients do not rely on unintended side effects. If asked, be ready to show a sample request and response for each method.

How do you use HTTP status codes effectively in REST APIs?

Start by grouping status codes into categories: 2xx success, 3xx redirection, 4xx client errors, and 5xx server errors, and explain the meaning of common codes like 200, 201, 204, 400, 401, 403, 404, 409, and 500. Describe your approach to choosing a code, for example returning 201 for resource creation and 409 for conflicting state like unique constraint violations. Give an example of an error response body you would return, such as {"error":"Conflict","message":"Email already in use","code":409}, and explain how clients can use that structured payload. Discuss how consistent error formats make client-side error handling easier, and include links to API docs or reference pages during interviews. Advise against returning 200 for all errors or leaking stack traces in responses, and recommend logging detailed errors server-side while returning safe, actionable messages to clients. Mention that you should document error schemas in your OpenAPI spec.

What is idempotency and why is it important for REST APIs?

Define idempotency as the property where repeating the same request yields the same result and has no additional side effects after the first application. Explain why idempotency matters for network retries, client crashes, and ensuring safe retries in distributed systems. Provide a concrete technique, such as implementing an idempotency key for POST endpoints that perform creation, for example clients include an Idempotency-Key header and the server stores the result for that key. Describe an example flow where a payment creation call is retried because of a network timeout, and the idempotency key prevents duplicate charges. Also point out pitfalls, like assuming database uniqueness always enforces idempotency without proper transaction handling, and discuss cleanup policies for stored idempotency keys to avoid unbounded storage growth. Emphasize testing retry scenarios during QA to validate behavior.

How do you design RESTful endpoints and resource hierarchies?

Begin with the principle of modeling endpoints around nouns that represent resources, not actions, for example /orders rather than /createOrder. Explain how you choose resource names, nesting only when necessary, and how you represent relationships with subresources or links. Provide a concrete design example: /projects/{projectId}/tasks for tasks tied to a project, and keep pagination and filtering on the top-level collection endpoints with query parameters like ?page=2&status=open. Describe how you handle actions that do not map cleanly to CRUD by using controller endpoints like /users/{id}/reset-password with POST when state change is needed. Warn against deep nesting that makes URIs long and hard to cache, and recommend using relations or reference IDs rather than nesting multiple levels whenever possible. Mention you should include clear documentation and examples for each endpoint to guide client developers.

How do you handle authentication and authorization for REST APIs?

Explain the separation: authentication proves who the client is, and authorization determines what they can do. Discuss common approaches you would present, such as API keys for machine-to-machine, OAuth 2.0 for delegated access, and JWTs for stateless session tokens, and when each fits best. Give a practical example, for example using OAuth 2.0 with bearer tokens for third-party access and including scopes to limit actions like read:orders versus write:orders. Describe how you validate tokens, check scopes or roles on protected endpoints, and refresh tokens securely when needed. Point out common security mistakes to avoid, such as storing secrets in client-side code, using overly long-lived tokens, or not validating token audience and issuer. Recommend transport security with TLS and rate limiting as complementary protections.

What strategies do you use for API versioning?

Start by explaining the main versioning strategies: URI versioning like /v1/resource, header versioning, and content negotiation with Accept headers, and describe why you would pick one over another. Emphasize practical trade-offs, for example URI versioning is explicit and simple while header versioning keeps URIs clean but can complicate caching and tooling. Give an example migration plan, such as releasing v2 with additive, backward-compatible changes, running both v1 and v2 for a deprecation window, and providing migration guides with code examples. Describe how you use semantic versioning for backend libraries and clearly communicate breaking changes in release notes. Advise keeping versions for a limited time to reduce maintenance burden, and avoid breaking changes in minor releases by maintaining backwards compatibility where possible. Mention automated tests against multiple versions to prevent regressions.

How do you handle caching for REST APIs?

Explain caching mechanisms at different layers, including client caching, CDN caching, and server-side caches, and show how HTTP headers such as Cache-Control, Expires, ETag, and Last-Modified control caching behavior. Describe when you would use strong caching for immutable resources and conditional requests for resources that can change. Provide a specific example like returning ETag and handling If-None-Match to return 304 Not Modified when content has not changed, which reduces bandwidth and latency. Discuss cache invalidation techniques, for example using cache-busting versions in the resource path or sending cache-control: no-cache for frequently changing endpoints. Warn against caching dynamic personal data without proper Vary or authorization checks, and recommend testing cached responses for correctness under authentication scenarios. Note that caching often requires coordination between API design and client expectations.

How do you implement pagination, filtering, and sorting in REST APIs?

Describe common pagination strategies, such as offset-based pagination with page and limit parameters and cursor-based pagination using opaque cursors for large or changing datasets. Explain advantages and drawbacks, for example offset is simple but can be inefficient or inconsistent with concurrent writes while cursor pagination is reliable at scale. Give a concrete example: /items?limit=25&cursor=abc123 for cursor-based pages, and include metadata in the response like nextCursor, hasMore, and totalCount when appropriate. For filtering and sorting, recommend descriptive query parameters such as ?status=active&sort=created_at:desc and validate filters server-side to prevent injection. Advise including sensible defaults and maximum limits to protect the API from expensive queries, and document filterable fields and sort options clearly in your API docs. Mention the importance of indexing database columns used for filtering and sorting to keep queries performant.

How do you document and test REST APIs?

Start by saying you should use a machine-readable specification such as OpenAPI (Swagger) to describe endpoints, parameters, request and response schemas, and example payloads. Explain how documentation improves developer onboarding and enables generation of client SDKs and interactive docs for quick testing. Provide a practical testing approach: write unit tests for controllers, integration tests against a staging environment, and contract tests with tools like Pact to verify client and server compatibility. Mention tooling such as Postman or HTTPie for manual exploration and CI pipelines that run automated API tests on every build. Advise keeping documentation and specs in version control and updating them as part of your change process, not as a separate afterthought. Recommend running smoke tests after deployments to catch environment-specific issues early.

Describe a time you diagnosed and fixed a production API outage.

Situation: Briefly explain the incident, for example an API endpoint returned 500 errors during peak traffic and customer requests failed for 30 minutes. Task: Your responsibility was to identify the root cause, restore service quickly, and prevent recurrence. Action: Describe steps you took, such as checking logs and metrics to find a slow database query, applying a quick mitigation like enabling a cache or scaling the read replicas, while coordinating with the on-call and communicating status to stakeholders. Include specific technical actions you took, for example rolling back a recent deployment and patching the problematic query. Result: State measurable outcomes, for example you restored 95 percent of functionality within 20 minutes, reduced error rate to normal, and later implemented a query fix and added alerts which prevented similar incidents. Reflect on lessons learned, such as improving monitoring and runbooks for faster detection.

Tell me about a time you improved API performance.

Situation: Describe the performance problem, for example an API list endpoint had rising latency causing timeouts for clients. Task: Your goal was to reduce latency and improve throughput while preserving data correctness. Action: Explain what you did, such as profiling queries, adding appropriate indexes, introducing cursor pagination, and adding caching at the CDN for static responses. Mention how you measured impact using request latency percentiles and load testing to validate changes. Result: Share results with metrics, for example 95th percentile latency dropped from 800ms to 120ms and error rates fell by 70 percent, and note how you added monitoring dashboards to detect regressions early. Mention how you documented the performance tuning steps for the team.

Give an example of collaborating on an API design with cross-functional teams.

Situation: Set the scene, for example you were part of a team building an API consumed by web, mobile, and third-party partners with differing needs. Task: Your role was to propose an API design that balanced flexibility, security, and maintainability across stakeholders. Action: Describe actions you took such as running a design workshop, creating OpenAPI drafts, gathering feedback from frontend, mobile, and security teams, and iterating on resource shapes and authentication flows. Explain specific compromises, such as adding optional fields for mobile while keeping payloads minimal for web. Result: Describe the outcome, for example the team approved the API spec, development proceeded with fewer integration issues, and partners completed integration two weeks earlier than expected. Note any follow-up actions such as creating sample SDKs and README guides to smooth adoption.

Explain the difference between PUT and PATCH and show a code example.

Explain conceptually that PUT should perform a full replacement of the resource while PATCH applies a partial update to one or more fields, and highlight idempotency differences: PUT is typically idempotent while PATCH may not be. Suggest using PATCH when clients need to update single fields without sending the full resource. Provide a short example in JSON over HTTP: a PUT to /users/123 with body {"id":123,"name":"Alex","email":"a@example.com"} replaces the whole user, while a PATCH to /users/123 with body {"op":"replace","path":"/email","value":"new@example.com"} or a simpler partial JSON body {"email":"new@example.com"} updates just that field. Explain that JSON Patch (RFC 6902) is a formal option for complex diffs while simpler partial objects are common in many APIs. Mention pitfalls such as clients accidentally overwriting fields with nulls on PUT if they omit fields, and recommend clear documentation and validation to avoid unintended data loss. Suggest tests that simulate both full replace and partial update scenarios.

How do you secure REST APIs using JWT and what are common gotchas?

Start by explaining the JWT flow: authentication server issues a signed token that clients send as a Bearer token in the Authorization header, and the API verifies signature and claims like issuer, audience, and expiry. Note that JWTs can be stored server-side for revocation lists or kept stateless if you accept the trade-off that immediate revocation is harder. Show a brief example of token verification logic in pseudocode: parse Authorization header, validate signature, check exp and aud claims, then extract user id and scopes for authorization checks. Explain common gotchas such as not validating the token signature, trusting unsigned tokens, storing sensitive data in token payload, and using overly long expiry times. Recommend rotating signing keys, using short-lived access tokens with refresh tokens, and keeping sensitive state on the server rather than in tokens. Advise running token validation in middleware and logging suspicious verification failures for security audits.

What is CORS and how do you configure it for a REST API?

Define CORS as a browser security feature that restricts cross-origin HTTP requests initiated from scripts, and explain that servers control allowed origins, methods, and headers via response headers like Access-Control-Allow-Origin. Describe when you need CORS, typically when a web app on one domain calls an API hosted on another domain. Give a configuration example, for instance setting Access-Control-Allow-Origin to the specific web app origin, sending Access-Control-Allow-Methods with GET, POST, and setting Access-Control-Allow-Headers to include Authorization. Explain the role of preflight OPTIONS requests and how to respond to them quickly with the appropriate headers. Warn against using a wildcard origin with credentials since Access-Control-Allow-Credentials cannot be used with a wildcard and that opens security risks. Recommend restricting allowed origins and reviewing CORS headers during security testing.

How would you implement rate limiting and what are common approaches?

Start by explaining that rate limiting protects APIs from abuse and overload by capping requests per client or API key over a time window, and describe common policies like fixed window, sliding window, and token bucket. Explain when you would apply limits globally, per API key, or per IP depending on threat model and client patterns. Give a concrete implementation example, such as using Redis to store counters with TTLs for fixed-window limits or a leaky-bucket algorithm with timestamps for smoother throttling. Mention practical details like returning 429 Too Many Requests with Retry-After header and designing graceful degradation for rate-limited clients. Note pitfalls like clock skew in distributed systems and the need to account for burst traffic, and suggest monitoring and adaptive limits for high-value clients. Recommend documenting limits clearly and providing developer support channels for elevated quotas.

How do you design error responses and what should they include?

Explain that error responses should be consistent, machine-readable, and actionable, typically including an HTTP status code, an error code, a human-friendly message, and optional details for debugging. Recommend a JSON schema example such as {"error":"InvalidRequest","message":"Missing field 'email'","details":{"field":"email"},"timestamp":"..."}. Describe how you differentiate client errors from server errors and include links to API docs or error code references to help integrators resolve issues. Suggest including correlation IDs in responses so clients can report issues and you can trace requests in logs. Warn against exposing internal debug information like stack traces to clients, and emphasize logging full details server-side while returning safe messages to callers. Recommend automated tests that assert error shapes for common failure modes.

How do you test REST APIs, and which tools and strategies do you use?

Outline a layered testing approach including unit tests for controllers and services, integration tests against a test database, contract tests for client-server agreements, and end-to-end tests for full workflows. Mention tools you would use such as Jest or JUnit for unit tests, Postman or Newman for manual and automated API testing, and Pact for consumer-driven contract tests. Give an example CI workflow that runs unit and integration tests on pull requests, runs contract tests when services change, and executes a small set of smoke tests against a staging environment before deployment. Describe using fixtures and test data patterns to keep tests deterministic and fast. Caution about brittle end-to-end tests that depend on external systems, and recommend mocking third-party APIs or using recorded responses for reliability. Advocate for monitoring in production as a final safety net since tests cannot cover every real-world scenario.

rest api Interview Questions: Complete Guide

rest api interview questions often cover HTTP fundamentals, API design, security, and debugging scenarios across technical screens and behavioral interviews. You can expect whiteboard design, live coding or take-home tasks, and scenario questions during system design or behavioral rounds. Stay calm, explain trade-offs, and show how you validate and test your work.

Common Interview Questions

Behavioral Questions (STAR Method)

STAR Method: Structure your answers using Situation, Task, Action, and Result to tell compelling stories about your experience.

Technical Questions

Questions to Ask the Interviewer

Show your interest by asking thoughtful questions

•What does success look like for this role after six months and what metrics will measure it?
•Can you describe the team structure, how the API team works with frontend and DevOps, and who I would collaborate with daily?
•What are the current technical constraints or debt in your API stack that the team is focused on resolving?
•How do you approach API documentation, versioning, and support for third-party integrators here?
•What monitoring and alerting practices do you have for production APIs, and how do you handle incident response?

Interview Preparation Tips

Practice explaining trade-offs out loud, for example why you chose cursor pagination over offset for a given scale scenario.

Bring short code snippets or OpenAPI examples to interviews to walk through your design decisions with concrete artifacts.

When answering architecture questions, start with requirements and constraints, then propose options and justify your choice with pros and cons.

Prepare one or two concise stories about production incidents and performance improvements, with measurable results you can cite during behavioral rounds.

Overview

### What this guide covers This page prepares you to answer REST API interview questions with clarity and examples. You will learn core HTTP concepts, REST design trade-offs, security patterns, performance considerations, and how to explain real-world tradeoffs in 2–3 minute answers.

### Core concepts to master

•HTTP verbs and semantics: explain GET (safe), POST (create), PUT (replace), PATCH (partial update), DELETE (remove). Cite idempotency: GET, PUT, DELETE are idempotent; POST is not.
•Status codes: give quick examples—200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests, 500 Internal Server Error.
•Resource modeling: use nouns, e.g., /orders/{orderId}/items; avoid verbs in endpoints.

### Practical interview examples

•E-commerce catalog: show GET /products?category=shoes&limit=20 (pagination offset=0, limit=20) and cursor-based pagination for large datasets to reduce latency.
•Payment flow: explain idempotency keys for POST /payments to avoid double charges.

### Performance and security at a glance

•Target API latency < 200 ms for user-facing endpoints; cache responses with Cache-Control: max-age=60 for data that can be 1-minute stale.
•Authentication: compare short-lived JWT (15 minutes) plus refresh tokens versus API keys for internal services.

Actionable takeaway: memorize 8–10 status codes, practice 3 concrete examples (catalog, auth, payments), and rehearse a 90-second explanation of idempotency and error handling.

Key Subtopics to Prepare

### 1.

•What to know: methods, headers, status codes, content negotiation (Accept/Content-Type).
•Interview angle: explain when to use 301 vs 302, or when to return 202 Accepted for async work.

### 2.

•Patterns: URI versioning (/v1/...), header versioning (Accept: application/vnd.example.v2+json), and semantic versioning for breaking changes.
•Example answer: "Use URI versions for public APIs and feature flags for internal clients."

### 3.

•Use structured JSON errors (RFC 7807 Problem Details). Include correlationId for tracing.
•Example: return {"type":"/errors/invalid-input","status":400,"detail":"email is required","instance":"/users"}.

### 4.

•Compare OAuth2 authorization code (user login) vs client_credentials (service-to-service). Mention JWT expiry (e.g., 900s = 15 min) and refresh tokens.

### 5.

•Tools: Postman, curl, Newman for CI. Use circuit breakers and retries with exponential backoff (first retry after 100ms, doubling).

### 6.

•Caching (CDN, Cache-Control), pagination (cursor vs offset), compression (gzip/ brotli), and rate limiting (e.g., 1,000 req/min).

Actionable takeaway: prepare a 30–60 second explanation and an example for each subtopic above; rehearse using a real endpoint you built or a public API.

Practical Resources and Next Steps

### Documentation and standards (read 2–3 hours each)

•Fielding’s REST principles and RFC 7231 (HTTP/1.1 semantics) for status code rules.
•OpenAPI Specification: learn to read and write a simple spec; aim to author a 20-endpoint OpenAPI file.

### Books and courses (pick 1–2)

•"RESTful Web APIs" (Richardson & Ruby) for design patterns—read 2 chapters per day.
•Pluralsight or Udemy courses on REST and API design; complete a 4–6 hour course and build the sample project.

### Tools to practice (hands-on)

•Postman: import a public collection and run 50 requests to test pagination and rate limits. Use Newman in CI to run those tests automatically.
•Swagger Editor / Swagger UI: generate client stubs and inspect request/response shapes.

### Performance and security tooling

•k6 or JMeter: run a simple load test with 500 concurrent users for 60 seconds to observe response times.
•OWASP API Security Top 10: study the top 5 and prepare examples of mitigation.

### Code and sample projects

•Clone or fork a lightweight REST API from GitHub, add OpenAPI docs, implement pagination and JWT auth, and deploy to a free cloud tier (e.g., 1–2 hours).

Actionable takeaway: spend 6–8 hours across one week: 2 hours reading specs, 3 hours building a sample API, and 1–3 hours running tests and writing a short README describing your design choices.

rest api Interview Questions: Complete Guide

Emily Thompson

Common Interview Questions

Behavioral Questions (STAR Method)

Technical Questions

Questions to Ask the Interviewer

Interview Preparation Tips

Overview

Key Subtopics to Prepare

Practical Resources and Next Steps

Common Interview Questions

Build your job search toolkit

rest api Interview Questions: Complete Guide

Emily Thompson

Common Interview Questions

Q1What is a REST API and what are its main principles?

Q2Can you explain common HTTP methods and when to use each?

Q3How do you use HTTP status codes effectively in REST APIs?

Q4What is idempotency and why is it important for REST APIs?

Q5How do you design RESTful endpoints and resource hierarchies?

Q6How do you handle authentication and authorization for REST APIs?

Q7What strategies do you use for API versioning?

Q8How do you handle caching for REST APIs?

Q9How do you implement pagination, filtering, and sorting in REST APIs?

Q10How do you document and test REST APIs?

Behavioral Questions (STAR Method)

B1Describe a time you diagnosed and fixed a production API outage.

B2Tell me about a time you improved API performance.

B3Give an example of collaborating on an API design with cross-functional teams.

Technical Questions

T1Explain the difference between PUT and PATCH and show a code example.

T2How do you secure REST APIs using JWT and what are common gotchas?

T3What is CORS and how do you configure it for a REST API?

T4How would you implement rate limiting and what are common approaches?

T5How do you design error responses and what should they include?

T6How do you test REST APIs, and which tools and strategies do you use?

Questions to Ask the Interviewer

Interview Preparation Tips

Overview

Key Subtopics to Prepare

Practical Resources and Next Steps

Common Interview Questions

Build your job search toolkit