REST APIs Explained | Interview Guide

REST APIs

REST APIs Explained: The Language of Modern Web & Mobile Apps

A complete interview-ready guide covering REST principles, HTTP methods, status codes, design patterns, security, caching, versioning, and real-world examples to help you explain REST clearly and confidently.

Focus: explain REST principles, JSON over HTTP, CRUD operations, and practical design choices — with examples and a 10-question quiz for interview prep.

Table of Contents

• Introduction
• REST Principles
• HTTP Methods
• Status Codes
• Resource & URI Design
• Security
• Caching & Performance
• Versioning Strategies
• Example: CRUD Operations
• Best Practices
• Interview Strategy
• 10 Question Quiz
• Final Thoughts

Introduction

REST (Representational State Transfer) is an architectural style for building web services that are simple, scalable, stateless, and use standard HTTP methods. REST is not a protocol — it is a set of principles and constraints that guide how web APIs should be designed to maximize compatibility with the web and HTTP infrastructure.

At interview level, explaining REST well means more than repeating the acronym. You should be able to describe why REST favors resources (nouns) over actions (verbs), how HTTP methods map to CRUD, and how statelessness, caching, and uniform interfaces enable scalable systems. Recruiters and interviewers look for explanations that connect theory to practical choices you might make when designing an API.

This guide covers REST core principles, HTTP method usage, status codes, common design patterns, and practical topics like authentication, rate limiting, caching, and versioning. It also includes real-world examples and a 10-question quiz to test your knowledge.

REST Principles

REST is defined by a set of constraints that, when adhered to, produce scalable and maintainable APIs. The most important constraints are:

• Client–Server: Separation of concerns between client (UI) and server (data + logic) simplifies development and scaling.
• Statelessness: Each request contains all information needed to process it. Servers do not store client state between requests, which allows easy scaling and better reliability.
• Cacheable: Responses must declare whether they are cacheable. Proper caching reduces latency and load on servers.
• Uniform Interface: A consistent way to interact with resources (URIs + HTTP methods) makes APIs easier to learn and use.
• Layered System: Architecture can be composed of layers like caching, load balancers, and security gateways without the client needing to know the real backend.
• Code on Demand (optional): Servers can optionally send executable code (like JavaScript) to extend client functionality — rarely used in modern APIs.

When answering interview questions, mention these constraints and illustrate with examples: statelessness enables horizontal scaling, caching reduces latency, and the uniform interface simplifies client implementations.

HTTP Methods

HTTP methods map naturally to CRUD operations. Use them consistently:

Method	Purpose	Idempotent	Safe
GET	Read / retrieve a resource	Yes	Yes
POST	Create a new resource / trigger processing	No	No
PUT	Replace a resource completely	Yes	No
PATCH	Update part of a resource	No (but can be made idempotent)	No
DELETE	Remove a resource	Yes	No

Explain idempotence in interviews: a client can safely retry an idempotent request without causing unintended side effects. For example, multiple identical DELETE requests after the first will have the same effect: the resource is gone.

HTTP Status Codes

Use status codes to communicate the result of requests. A few important ones to know:

2xx Success

200 OK, 201 Created, 204 No Content — use 201 when creating resources and include a Location header.

3xx Redirection

301, 302 — used for moved resources or temporary redirects.

4xx Client Error

400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422 Unprocessable Entity.

5xx Server Error

500 Internal Server Error, 503 Service Unavailable — indicate server-side problems.

Good interview answers show that you can choose appropriate status codes and understand their semantics. For example: respond 400 for malformed JSON, 401 for missing or invalid credentials, and 403 when credentials are valid but access is denied.

Resource & URI Design

Design resources around nouns, not verbs. A good URI structure is predictable and hierarchical:

• /users — collection of users
• /users/{id} — single user resource
• /users/{id}/orders — sub-collection

Prefer plural nouns for collections and avoid action words in URIs. Use query parameters for filtering, sorting, and pagination: /products?category=books&page=2&limit=20.

Security

Security is central to any public API. Key interview talking points:

• Authentication: Use tokens (OAuth2, JWT) or API keys depending on context. For user-facing APIs, OAuth2 (Authorization Code flow) is standard.
• Authorization: Implement fine-grained authorization, enforce least privilege, and check on each request.
• Transport: Always use HTTPS to protect data in transit.
• Input validation: Validate and sanitize inputs to prevent injection attacks.
• Rate limiting: Protect the API from abuse and enforce fair usage (more below).
• Logging & monitoring: Log security events and monitor for anomalies.

Caching & Performance

Caching reduces latency and backend load. Discuss cache-control headers and cache invalidation strategies:

• Cache-Control: Use directives like public, max-age=3600 for cacheable responses.
• ETags & conditional requests: Use ETag/If-None-Match to allow clients to revalidate resources efficiently.
• CDNs: Offload static or cacheable API responses to a CDN for global performance.
• Denormalization & caching layers: Introduce caching at the database or application layer for heavy read patterns.

In interviews, explain trade-offs: aggressive caching improves latency but complicates invalidation. Show you understand TTLs, stale-while-revalidate, and cache purging.

Versioning Strategies

APIs evolve. Versioning ensures backward compatibility. Common approaches include:

• URI versioning: /v1/users — explicit and easy to route.
• Header versioning: Use custom Accept headers (more RESTful but less visible).
• Semantic versioning & deprecation policy: Communicate breaking changes clearly and provide migration guides.

Good interview answers pick an approach and justify it: URI versioning is simple and discoverable, header-based versioning decouples version from the URL but increases client complexity.

Example: CRUD Operations

Here is a compact CRUD example for a users resource:

• Create: POST /users with JSON body — returns 201 Created and Location header.
• Read (all): GET /users — returns 200 OK and a JSON array.
• Read (one): GET /users/{id} — returns 200 OK or 404 Not Found.
• Update: PATCH /users/{id} — partial update; PUT for full replace.
• Delete: DELETE /users/{id} — returns 204 No Content on success.

// Example request (create user)
POST /users HTTP/1.1
Content-Type: application/json

{"name":"Jane Doe","email":"jane@example.com"}

// Example response
HTTP/1.1 201 Created
Location: /users/123
{"id":123,"name":"Jane Doe","email":"jane@example.com"}
    

Best Practices

• Use nouns for resources and HTTP methods for actions.
• Return appropriate status codes and helpful error payloads with machine-readable fields (e.g., {"error":"invalid_input","details":{...}}).
• Document your API with OpenAPI / Swagger and provide examples.
• Use pagination for large collections (cursor-based for large-scale systems).
• Support filtering and sorting via query parameters and avoid embedding complex queries in the URI path.
• Provide clear rate limiting headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset).

Interview Strategy

When asked about REST in interviews, structure your answer:

1. Define REST and its constraints (client-server, stateless, cacheable, uniform interface).
2. Map HTTP methods to CRUD with examples.
3. Discuss status codes, caching, and versioning choices.
4. Explain security considerations (HTTPS, tokens, authorization).
5. Give a concise real-world example and explain trade-offs.

Always tailor your depth to the interviewer's level — for senior roles, discuss rate limiting strategies, idempotency design, id-based versus cursor pagination, and scaling considerations like sharding or CQRS for high write loads.

10 Question Quiz

Test your knowledge — choose the best answer for each.

1. Which HTTP method should you use to create a new resource? GET POST PUT DELETE

2. Which status code indicates a created resource? 200 201 404 500

3. What does idempotent mean in HTTP? The method is safe and has no side effects Multiple identical requests have the same effect as one The method requires authentication It always returns 200

4. Which header is commonly used for caching? Authorization Cache-Control Content-Type X-Frame-Options

5. Which approach is simplest and most discoverable for versioning? URI versioning (/v1/) Header versioning only Cookie-based versioning No versioning

6. Which status code means unauthorized (authentication required)? 400 401 403 404

7. Which header indicates how many requests remain in a rate-limited window? X-RateLimit-Remaining Retry-After X-Powered-By Content-Length

8. For partial updates, which method is preferred? PUT PATCH POST GET

9. Which response is appropriate for a successful deletion? 200 OK with body 204 No Content 201 Created 403 Forbidden

10. What is a good reason to design an API to be stateless? It simplifies horizontal scaling It enforces stateful session storage It makes clients depend on server memory It prevents caching

Final Thoughts

REST is the lingua franca of web APIs. For interviews, balance conceptual clarity with concrete examples: explain REST constraints, map HTTP to CRUD, show how status codes guide client behavior, and discuss practical trade-offs like caching versus freshness, versioning approaches, and security choices.

Being able to reason about idempotency, retries, safe methods, and how to design resource URIs demonstrates a pragmatic understanding. If you're preparing for senior roles, be ready to discuss scaling, rate limiting, observability, and contracts (OpenAPI) that help teams evolve APIs safely.

This guide and quiz give you both the vocabulary and practical patterns to answer REST-related interview questions clearly and confidently.