HTTP interview questions: methods, status codes, caching, cookies, and REST APIs

Webhook reliability requires the consumer to respond quickly (within the provider's timeout window, often 5–30 s) with a 2xx status to acknowledge receipt, then process asynchronously. If the consumer does heavy work synchronously and times out, the provider may retry, causing duplicate deliveries. Idempotency keys/event IDs let consumers deduplicate retries. Signature verification (HMAC) guards against spoofed payloads but does not help with duplicate delivery. Storing the raw payload before processing is the correct 'accept-then-process' pattern. The strategy of verifying the HMAC signature, persisting the raw payload to a durable queue/store, returning 200 OK immediately, and processing asynchronously — using the event ID to deduplicate before acting — describes returning a 200 immediately and queuing the work — the correct pattern — while the others describe anti-patterns or incomplete solutions.

When a request creates a new resource the correct status is 201 Created, and best practice is to include a Location header (e.g. /users/{id}) pointing at it (RFC 9110 §15.3.2). POST is a perfectly valid way to create a subordinate resource, returning the representation in the body is fine, and 204 would be wrong because there is a body to send.

HttpOnly is a core defence for session cookies: even if an attacker injects script via XSS, they cannot steal the cookie through the DOM. It does not prevent the cookie from being sent, so SameSite and CSRF tokens remain necessary for cross-site request protection.

Access tokens are intentionally short-lived to limit the damage window if they are compromised; once expired, the client must use a long-lived refresh token to get a new one without forcing the user to log in again. The state parameter acts as a CSRF mitigation: the client stores it locally (e.g., in session or a cookie), includes it in the authorization request, and then verifies that the value returned in the callback matches—preventing a malicious site from tricking the client into completing an authorization flow it did not initiate.

A robust webhook producer must handle consumer-side failures gracefully. The correct practices are: (1) retry with exponential back-off and jitter to avoid thundering-herd effects, (2) include a unique, stable event ID so consumers can deduplicate, (3) sign payloads (e.g., HMAC-SHA256) so consumers can verify authenticity, and (4) emit a full event envelope rather than just an identifier (although 'thin' notification + fetch is a valid alternative pattern). Delivering from a single IP without fallback, expecting synchronous processing in under 1 s, and omitting signatures are all anti-patterns. The event ID, the signed payload and retry with back-off are all correct best practices; delivering only to a fixed IP with no retry is not.

The ordering question covers the correct sequence for securely and reliably processing an inbound webhook. You must first read and buffer the raw body before any parsing so the HMAC can be computed over the exact bytes the sender signed. Next you verify the HMAC signature against the raw body — rejecting with 401/403 if invalid — before trusting any data. Then you parse/deserialize the verified payload. After that you perform idempotency check using the event ID so duplicate retries are ignored. Finally you enqueue the work for async processing and return 200 OK. Reversing signature verification and parsing, or checking idempotency before verifying authenticity, are both security or correctness errors.

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.

RFC 7519 §4.1.4 mandates that JWT processors MUST reject tokens where the current time is at or after the exp value. RFC 6750 §3.1 specifies that an expired token is an invalid_token error and the resource server MUST respond with HTTP 401 and a WWW-Authenticate header carrying error="invalid_token". The azp claim (authorized party) is checked by the client, not required by the resource server for basic validation. The aud as a URI is perfectly valid per RFC 7519 §4.1.3. RFC 7519 does acknowledge that implementors may allow small clock skew, but it is not a default tolerance, and 'MUST reject' takes precedence — accepting is never the correct answer once past exp.

windowStart = now - windowSecs = 1000 - 5 = 995. The filter t > 995 (strictly greater than) drops 994 (which equals 995 − 1, not strictly greater) and keeps [996, 998, 999] — that is 3 entries. Since 3 < 4 (the limit), the if branch is not taken; the else branch runs, pushes 1000 onto recent making its length 4, and logs 200 OK. Requests in window: 4. The output 429 Too Many Requests. Retry-After: 1s would be the output only if all four prior timestamps were in-window (i.e., recent.length >= 4 before the push), but that is not the case here because 994 is excluded by the strict > comparison.

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.