Top 20 REST API Interview Questions and Answers (2026 Guide)

Application Programming Interfaces (APIs) represent the connective tissue of modern software. Every web application, mobile app, microservice mesh, and analytics data ingestion pipeline relies on RESTful APIs to exchange structured data over HTTP.

When technical interviewers ask rest api interview questions, they are not merely checking if you have memorized status codes. They want to know: Do you design clean, intuitive resource paths? Do you understand how to make distributed writes resilient to network retries with idempotency? How do you prevent unauthorized privilege escalation?

In this comprehensive guide, we dissect the top 20 rest api interview questions, complete with HTTP request/response payloads, security best practices, and architectural trade-offs. To review backend and API implementations, check our companion guides on FastAPI Interview Questions, Python Basic Interview Questions, and our comprehensive Python tutorial.

Top 20 REST API Interview Questions and Answers

Q1: What is REST and what are its 6 architectural constraints?

Answer: REST (Representational State Transfer) is an architectural style defined by Roy Fielding for building distributed hypermedia systems over HTTP. The 6 core constraints are:

1. Client-Server Separation: User interface concerns are separated from data storage, allowing both to scale independently.
2. Statelessness: Every request from client to server must contain all necessary context; no client state is stored on the server between requests.
3. Cacheability: Responses must declare whether they are cacheable to prevent clients from resending redundant requests.
4. Uniform Interface: Standardized URIs, HTTP verbs, and self-descriptive messages (the hallmark of REST).
5. Layered System: The client cannot tell whether it is connected directly to the end server or an intermediate proxy, load balancer, or CDN.
6. Code on Demand (Optional): Servers can temporarily extend client functionality by transferring executable code (e.g. JavaScript).

Q2: What is the difference between PUT and PATCH?

Answer:

• PUT (Full Resource Replacement): The client sends a complete representation of the resource. Any field omitted in the payload is overwritten or cleared. PUT is idempotent: running the identical PUT request 10 times leaves the server in the exact same state as running it once.
• PATCH (Partial Resource Update): The client sends only the specific attributes that need modification. Unspecified fields remain untouched. PATCH is not inherently idempotent (for example, a JSON-PATCH payload executing {"op": "increment", "amount": 10} changes server state on every invocation).

# PUT: Replaces the complete customer object
PUT /api/v1/customers/101
Content-Type: application/json
 
{
  "name": "Priya Sharma",
  "email": "priya@example.com",
  "city": "Bengaluru"
}
 
# PATCH: Updates only the email address
PATCH /api/v1/customers/101
Content-Type: application/json
 
{
  "email": "priya.new@example.com"
}

Q3: What is Idempotency and which HTTP methods are idempotent?

Answer: An HTTP method is idempotent if making multiple identical requests has the same effect on the server state as making a single request.

• Idempotent:
  • GET: Safe and read-only.
  • HEAD: Identical to GET without the response body.
  • PUT: Overwriting with identical data produces the same final record.
  • DELETE: Deleting ID 101 once removes it. Repeating the delete still results in ID 101 being gone (even if subsequent responses return 404 Not Found, the server state is identical).
• Non-Idempotent:
  • POST: Calling POST /orders five times creates five distinct orders.

Handling Non-Idempotent Writes Safely: Payment APIs use an Idempotency-Key header (e.g. UUID) so the server caches the first response and skips processing duplicated network retries.

Q4: Explain the key HTTP Status Code categories with examples.

Answer:

• 2xx Success:
  • 200 OK: Request succeeded (standard response for GET, PUT).
  • 201 Created: Resource successfully created (standard response for POST).
  • 204 No Content: Request succeeded but no response body returned (standard for DELETE).
• 3xx Redirection:
  • 301 Moved Permanently: Resource has a permanent new URI.
  • 304 Not Modified: Cached copy on client is still fresh.
• 4xx Client Error:
  • 400 Bad Request: Malformed JSON or failed schema validation.
  • 401 Unauthorized: Authentication is missing or invalid.
  • 403 Forbidden: Authenticated, but lacking permission/role.
  • 404 Not Found: Resource URI does not exist.
  • 409 Conflict: Request conflicts with current state (e.g. duplicate email).
  • 429 Too Many Requests: Client exceeded rate limit.
• 5xx Server Error:
  • 500 Internal Server Error: Unhandled server exception.
  • 502 Bad Gateway: Upstream microservice failed to respond.
  • 503 Service Unavailable: Server overloaded or undergoing maintenance.

Q5: What is the difference between Authentication and Authorization?

Answer:

• Authentication (AuthN): Verifies who you are. The client proves their identity using credentials (passwords, API keys, JWT tokens).
• Authorization (AuthZ): Verifies what you are allowed to do. Once authenticated, the server evaluates Role-Based Access Control (RBAC) to decide whether the user can perform the requested action (e.g. admin vs read-only member).

Q6: How does JWT (JSON Web Token) authentication work in REST APIs?

Answer: A JWT consists of three Base64URL-encoded parts separated by dots: Header.Payload.Signature.

1. Login: Client posts credentials to /auth/login.
2. Issue: Server validates credentials, encodes user ID and roles into the payload, signs the token using a secret key (HMAC SHA-256) or private key (RSA/ECDSA), and returns the token to the client.
3. Request: Client attaches the token to subsequent requests in the header:

   http

   Copy code

   Authorization: Bearer eyJhbGciOiJIUzI1Ni...

4. Verification: The server computes the signature using its secret. If the signature matches and expiration (exp) has not passed, the request is authenticated without querying a database or session store.

Q7: What is CORS and how do you resolve CORS errors?

Answer: CORS (Cross-Origin Resource Sharing) is a browser security mechanism that blocks web pages hosted on one origin (domain, protocol, or port) from making asynchronous requests to a different origin.

How it works:

1. For state-changing requests, the browser sends an HTTP OPTIONS preflight request.
2. The server must respond with matching CORS headers:

   http

   Copy code

   Access-Control-Allow-Origin: https://dashboard.topfolio.in
   Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
   Access-Control-Allow-Headers: Authorization, Content-Type

3. If the server does not return the requesting origin, the browser blocks the response.

Q8: How do you design Pagination in REST APIs (Offset vs Cursor)?

Answer:

• Offset-Based Pagination (GET /users?page=3&limit=20):
  • Uses SQL OFFSET 40 LIMIT 20.
  • Pros: Easy to jump to arbitrary page numbers.
  • Cons: Slow on large tables ($O(n)$ row scanning), and vulnerable to page drift (if an item is deleted while a user navigates, records shift and repeat).
• Cursor-Based (Keyset) Pagination (GET /users?limit=20&cursor=usr_1092):
  • Uses SQL WHERE id > 'usr_1092' ORDER BY id ASC LIMIT 20.
  • Pros: $O(1)$ index lookup speed, zero page drift, ideal for infinite scrolling feeds.
  • Cons: Cannot jump directly to page 50.

Q9: What are URI design best practices in REST?

Answer:

1. Use Nouns, Not Verbs: Resources represent entities, while HTTP methods supply the actions.
   • Good: POST /api/v1/orders
   • Bad: POST /api/v1/createOrder
2. Plural Nouns: Keep resource collections plural: /users, /invoices.
3. Hierarchical Relationships: Represent sub-resources clearly:
   • GET /users/101/orders (Orders belonging to User 101).
4. Filter with Query Parameters:
   • GET /orders?status=shipped&sort=date_desc

Q10: How do you handle API Versioning?

Answer:

1. URI Path (Most Popular & Practical):
   • /api/v1/customers vs /api/v2/customers
   • Clear, easily routed by API gateways, and cacheable.
2. Custom Request Header:
   • X-API-Version: 2
   • Keeps URIs clean, but harder to test directly in browser address bars.
3. Accept Header (Content Negotiation):
   • Accept: application/vnd.company.v2+json
   • Strictly adheres to REST purity, but more complex for clients to configure.

Q11: What is Rate Limiting and what algorithms are used?

Answer: Rate limiting controls the number of requests a client can submit within a time window to prevent DoS attacks, protect backend resources, and monetize API tiers. When exceeded, the server returns 429 Too Many Requests.

Core Algorithms:

• Token Bucket: Tokens refill at a constant rate up to a bucket capacity. Allows burst traffic while enforcing average rate.
• Leaky Bucket: Requests enter a queue and process at a strictly smooth, constant rate.
• Fixed Window Counter: Resets every minute; vulnerable to bursts right at window boundaries.
• Sliding Window Log / Counter: Smooths window boundaries by blending current and prior window request counts.

Q12: Compare REST vs GraphQL.

Answer:

Q13: What is HATEOAS in REST?

Answer: HATEOAS stands for Hypermedia As The Engine Of Application State. It is the final maturity level of REST (Richardson Maturity Model Level 3). The server includes hypermedia navigation links within resource payloads, instructing the client what actions are currently valid:

{
  "order_id": 101,
  "status": "pending_payment",
  "amount": 2500,
  "_links": {
    "self": { "href": "/orders/101" },
    "payment": { "href": "/orders/101/pay", "method": "POST" },
    "cancel": { "href": "/orders/101/cancel", "method": "DELETE" }
  }
}

Q14: How does HTTP Caching work with ETags and Cache-Control?

Answer:

• Cache-Control: max-age=3600, public: Instructs browsers and CDNs to cache the response for 1 hour without revalidating.
• ETag (Entity Tag): A hash digest representing the resource state. On subsequent requests, the client sends:

  http

  Copy code

  If-None-Match: "68b329da9893e34099c7d8ad5cb9c940"

  If the resource hasn't changed, the server responds with 304 Not Modified without retransmitting the response body, saving bandwidth.

Q15: What is Content Negotiation in REST APIs?

Answer: The mechanism allowing a client to request a specific data format:

• Client sends: Accept: application/json or Accept: text/csv.
• Server responds with the requested format and declares Content-Type: application/json. If the server cannot support the requested format, it returns 406 Not Acceptable.

Q16: What are Webhooks and how do they differ from API Polling?

Answer:

• Polling: The client repeatedly calls GET /orders/101/status every 10 seconds to check if payment cleared. Wastes bandwidth and compute.
• Webhooks (Reverse APIs): The client registers a callback URL (e.g. https://myapp.com/webhooks/payment). When the payment event occurs, the server issues an asynchronous HTTP POST directly to the client's endpoint with the event payload.

Q17: What is an Insecure Direct Object Reference (IDOR) in APIs?

Answer: IDOR occurs when an API endpoint uses an untrusted user-supplied identifier (like GET /invoices/5082) without verifying whether the authenticated user actually owns that resource. An attacker can iterate through invoice IDs and scrape confidential records.

• Prevention: Always enforce object-level authorization: WHERE invoice_id = :id AND user_id = :current_user_id.

Q18: What is Mass Assignment and how do you prevent it?

Answer: Mass assignment occurs when an API binds incoming JSON payloads directly to database entity models. For example, sending {"name": "Arjun", "is_admin": true} when registering an account. If the backend does not filter fields, a regular user can make themselves an administrator.

• Prevention: Use Data Transfer Objects (DTOs) or Pydantic schemas that explicitly declare allow-listed input fields.

Q19: What is the difference between REST and gRPC?

Answer:

• REST: Text-based (JSON over HTTP/1.1 or HTTP/2), human-readable, universally supported by browsers, ideal for public-facing client-server APIs.
• gRPC: Binary serialization (Protocol Buffers over HTTP/2), strictly typed, supports bi-directional streaming, 5–10x faster with smaller payloads, ideal for internal microservice-to-microservice communication.

Q20: How do you handle breaking changes in REST APIs?

Answer:

1. Introduce a New Version: Never modify or remove existing fields on /v1. Stand up /v2 alongside /v1.
2. Deprecation Headers: Include sunset warnings:

   http

   Copy code

   Sunset: Wed, 11 Nov 2026 00:00:00 GMT
   Deprecation: @1762819200

3. Additive Non-Breaking Changes: Adding a new optional field or new endpoint is backwards-compatible and does not require a version bump.

REST API Interview Questions by Difficulty

How to Prepare for REST API Technical Interviews

1. Practice Live cURL and Postman Testing: Know how to inspect raw HTTP headers, status codes, and query strings.
2. Review Security Vulnerabilities: Be ready to explain how to prevent IDOR, SQL injection, and broken object-level authentication.
3. Design APIs End-to-End: Practice designing resource schemas and endpoints for real-world scenarios like Ride Sharing, Food Delivery, or E-Commerce.

To practice building and testing real web APIs in Python, explore our FastAPI Interview Questions Guide.

Related Interview Guides

• Python Tutorial: Complete Guide for Analysts
• Data Analyst Interview Questions (2026 Edition)
• Python Basic Interview Questions
• SQL Interview Questions & Answers
• Explore All Guides in the Interview Prep Hub