HTTP & APIs Interview Questions — API Design Practice Quiz

RESTful URL design uses plural nouns to represent collections and nests child resources under their parent. The pattern GET /users/{userId}/orders reads naturally: 'get the orders belonging to the user with id userId'. Using nouns (not verbs) and hierarchical paths is a core REST design principle.

REST API design favors nouns over verbs in URL paths, and uses plural resource names to represent collections. The HTTP method (GET) already conveys the action, so embedding verbs like 'get' or 'fetch' in the path is redundant and violates REST conventions. /users is a clean, noun-based, plural resource path that correctly represents a collection of user resources.

Idempotency means that repeating the same operation multiple times yields the same server state as performing it once. PUT is defined as idempotent by the HTTP specification: sending PUT /users/1 with the same body replaces the resource each time, leaving the server in the identical state after the first call. This is unlike POST, which typically creates a new resource on each request and is therefore NOT idempotent.

HTTP status codes are grouped into five classes by their first digit: 1xx (Informational), 2xx (Success), 3xx (Redirection), 4xx (Client Error), and 5xx (Server Error). Understanding this classification is fundamental to API design and debugging — for example, knowing that a 404 is a client-side 'not found' error while a 502 is a server-side 'bad gateway' error.

REST conventions dictate that POST /orders creates a resource and should return 201 Created alongside a Location header pointing to the newly created resource. PATCH /orders/{id} is the correct verb for a partial update. GET /orders/delete?id=42 violates the constraint that GET must be safe and idempotent — deletion should use DELETE. PUT /orders without an identifier is semantically incorrect for updating a single resource; it would imply replacing the entire collection.

CORS preflight always begins with the browser automatically sending an OPTIONS request containing Origin and Access-Control-Request-Method (step a). The server replies with the allowed origins, methods, and headers (step b). The browser then validates those headers against the pending request (step e). Only if the preflight succeeds does the browser dispatch the actual request (step c), and the server finally responds with the resource plus CORS headers (step d).

Breaking changes are those that can cause existing well-written clients to behave incorrectly without modification. (a) Renaming full_name to name breaks clients that read full_name. (c) Removing internal_score breaks clients that depend on it. (d) Changing id's type from integer to string breaks clients that store or compare it as a number. (e) Returning 200 instead of 404 for a missing resource breaks clients that branch on HTTP status codes to detect absence. Adding a new optional field (b) is generally considered a non-breaking, additive change under most REST versioning contracts.

PATCH is the semantically correct method for partial updates per RFC 5789. PUT implies a complete replacement of the resource at the given URI; sending a partial body with PUT can lead to data loss or implementation-specific behavior. PATCH lets clients send a diff/patch document (often just a JSON subset) so only specified fields are changed. Strong candidates also note that PUT is idempotent and PATCH may be idempotent depending on the patch semantics, and that the server should return 200 or 204 on success.

HTTP/2 multiplexing eliminates head-of-line blocking at the HTTP layer by allowing multiple streams over a single TCP connection. However, TCP itself still suffers from head-of-line blocking at the transport layer — a single lost packet stalls all streams on that connection. HTTP/3 (QUIC) solves this by operating over UDP with per-stream loss recovery. The statement that HTTP/2 fully eliminates head-of-line blocking is therefore false; it only solves it at the application layer, not the transport layer.

This question tests deep knowledge of REST API design trade-offs for versioning strategies. URL path versioning (/v1/...) is simple and cache-friendly but pollutes the URI space and couples clients to implementation versions. Accept/Content-Type header versioning (media-type versioning, e.g., application/vnd.myapi.v2+json) is the most RESTful because URIs identify resources, not resource versions — it also enables content negotiation. However, it is harder to test in a browser and less visible in logs. Custom request header versioning (e.g., X-API-Version: 2) is not part of the HTTP standard and not cache-key-aware by default (requires a Vary header). Query parameter versioning (?version=2) is easy to use but semantically incorrect since query params should filter/sort resource representations, not identify API contracts. The key staff-level insight is that only media-type versioning preserves URI stability and leverages HTTP content negotiation correctly, making it the approach most aligned with REST constraints, even though URL versioning dominates in practice for pragmatic reasons.