REST API Interview Questions

REST stands for Representational State Transfer. Its core principles are: statelessness, client-server architecture, cacheability, uniform interface, layered system, and optional code-on-demand.

PUT replaces the entire resource with the provided data, requiring the full representation in the request body. PATCH applies a partial update, sending only the fields that need to change.

1xx Informational (100 Continue), 2xx Success (200 OK), 3xx Redirection (301 Moved Permanently), 4xx Client Error (404 Not Found), 5xx Server Error (500 Internal Server Error).

401 means the client is not authenticated — credentials are missing or invalid. 403 means the client is authenticated but does not have permission to access the resource.

A truly RESTful API must follow all REST constraints: stateless communication, uniform interface (resource-based URIs, standard HTTP methods, HATEOAS), and proper use of HTTP semantics like caching headers and status codes. Many APIs use HTTP but skip constraints like HATEOAS, making them REST-like but not fully RESTful.

HATEOAS (Hypermedia As The Engine Of Application State) means the API response includes links to related actions and resources, letting clients navigate the API dynamically without hardcoded URLs. It improves discoverability and decouples the client from the server's URL structure.

Common strategies are URI versioning (/v1/users), query parameter (?version=1), and Accept header versioning (Accept: application/vnd.api.v1+json). URI versioning is most visible and easy to test but pollutes the URL; header versioning is cleaner but harder to test in a browser; query params are simple but can conflict with caching.

An operation is idempotent if making the same request multiple times produces the same server state as making it once. GET, PUT, DELETE, HEAD, and OPTIONS are idempotent; POST and PATCH are generally not.

Common approaches are API Keys (simple but limited), OAuth 2.0 with Bearer tokens for delegated authorization, and JWT for stateless token-based auth. Tokens are sent in the Authorization header (Bearer scheme) and validated on each request since REST is stateless.

REST exposes multiple fixed endpoints per resource; GraphQL exposes a single endpoint where clients query exactly the data they need. Choose REST for simple, cacheable, resource-oriented APIs; choose GraphQL when clients have highly varied data needs or you want to avoid over- and under-fetching.

Common strategies are offset/limit (?offset=20&limit=10), page-based (?page=3&per_page=10), and cursor-based pagination using an opaque cursor token. Cursor-based is preferred for large or real-time datasets because it is stable under insertions/deletions, while offset pagination is simpler but can return duplicates or skip records on concurrent writes.

Rate limiting is typically enforced at the API gateway or middleware level using algorithms like token bucket or sliding window counter. The server returns 429 Too Many Requests with Retry-After or X-RateLimit-* headers so clients know when they can retry.

Error responses should use the appropriate HTTP status code, return a consistent JSON body with fields like error code, human-readable message, and optionally a details array or a link to documentation. Avoid exposing internal stack traces or sensitive system information in production error payloads.

The N+1 problem occurs when fetching a list of N resources then making one additional request per item to fetch related data, resulting in N+1 total requests. Solutions include eager loading/embedding related data in the response, implementing compound documents, using sparse fieldsets, or switching to GraphQL which resolves all fields in one query.

Use the async request-reply pattern: the POST immediately returns 202 Accepted with a Location header pointing to a status resource (e.g., /jobs/123). The client polls that endpoint until it returns 200 with the result or 303 See Other redirecting to the completed resource. Alternatively, use webhooks to push the result when ready.

Content negotiation allows clients and servers to agree on the format of the response. The client sends an Accept header (e.g., Accept: application/json) and the server responds with that format and a Content-Type header confirming it, or returns 406 Not Acceptable if the format is unsupported.

Strategies include: maintaining multiple versions simultaneously, using API sunset headers to deprecate old versions with a migration timeline, feature flags to toggle new behavior, and designing additive changes (new optional fields) whenever possible. Breaking changes should always increment the major API version.

An ETag is a hash or version identifier returned in the response header representing the current state of a resource. Clients can send it back in If-None-Match (for GETs) to receive 304 Not Modified if unchanged, reducing bandwidth, or in If-Match (for PUT/DELETE) to implement optimistic concurrency control and prevent lost updates.