Networking & HTTP Interview Questions

What is your convention for handling API errors in a frontend codebase?

Normalise at the boundary so the rest of the app branches on one shape. In the fetch wrapper: check `res.ok` before parsing, since a non-2xx body is usually not the shape you expect; distinguish network failure (fetch rejects), HTTP error (ok is false) and parse failure, because they are three different user-facing situations. Map the status to a decision — 401 triggers re-authentication, 403 does not retry, 404 is often an empty state rather than an error, 429 backs off using `Retry-After`, 5xx is retryable. Return a typed result rather than throwing a bare Error, so the type system forces callers to handle failure. Attach a request id so a user-reported error can be traced. And render the difference: "could not load" with a retry is not the same as "you have none".

The organising idea is to normalise once, at the boundary, so that four hundred call sites do not each invent their own interpretation of a failure. The three-way split matters because the three need different UI: a network failure is worth retrying automatically, an HTTP 4xx usually is not, and a parse failure means the contract is broken and retrying will not help. The 404-as-empty-state point is the one most often missed, and it is the difference between "you have no invoices" and an error page.

Build a resilient Server-Sent Events client that recovers missed messages

The `Last-Event-ID` mechanism is the whole reason SSE is attractive for this: resume is built into the protocol, provided the server actually assigns ids.

Walk through what happens between clicking a link and the first byte of the response arriving

DNS resolves the hostname to an IP (cached at several layers, so often free). TCP establishes a connection with a handshake — one round trip. For HTTPS, TLS negotiates on top of that — one or two more round trips depending on version and resumption. Only then does the request go out, the server does its work, and the first byte comes back. That is why TTFB on a distant or high-latency connection is dominated by round trips rather than by server time, and why `preconnect` to a critical third-party origin helps: it front-loads DNS, TCP and TLS so the actual request does not pay for them. It is also why reusing a connection (keep-alive, HTTP/2) matters so much — every new origin restarts this whole sequence.

The point of walking through it is that the round trips are the cost, not the server. On a high-latency connection a request can spend most of its time before the server has seen anything, which is why optimising a fast endpoint changes nothing and why connection reuse matters more than it looks. It also explains why each new third-party origin is expensive — the whole sequence restarts — and why `preconnect` helps for exactly one or two critical origins and is wasteful beyond that.

Every API call is preceded by an OPTIONS request, doubling latency. How do you reduce it?

await fetch(url, { headers: { 'Content-Type': 'application/json', 'X-Request-Id': id } });

Both headers force a preflight — `application/json` is outside the safelisted content types, and `X-Request-Id` is a custom header. You usually cannot avoid the preflight for a real JSON API, so the fix is to stop paying for it on every call: have the server return `Access-Control-Max-Age` so the browser caches the preflight result (capped by the browser, commonly a few hours or less), which removes the OPTIONS from all subsequent matching requests. Also make sure the preflight response is fast and not going through the full application stack, and consider whether moving the API to the same origin behind a path prefix removes CORS entirely.

The same-origin option is the one candidates forget — a reverse-proxy path is often simpler than tuning CORS caching.

You added retries with an idempotency key. Where does the key have to be generated, and why does that matter?

On the CLIENT, once, before the first attempt — and reused unchanged for every retry of that same logical operation. If the server generates it, or the client regenerates it per attempt, each retry looks like a new request and the duplicate protection disappears, which is exactly the case retries were meant to survive. The key must also be scoped to the operation rather than to the session, and persist across a page reload if the operation can outlive one, otherwise a user who refreshes mid-submit creates a second order. On the server side the key needs to be stored with the result so a replay returns the original outcome rather than re-executing, and it needs an expiry.

Drills the detail that makes the pattern work or fail: key generation timing is the whole mechanism.

When is Server-Sent Events a better fit than WebSockets?

SSE is one-way over ordinary HTTP, so it passes proxies easily, works with normal auth headers in most setups, and handles reconnection with event ids for free. WebSockets earn their extra complexity when the client also sends frequently, or you need binary.

Support reports that image uploads "sometimes just fail" on mobile. How would you investigate?

Get specifics before theorising: which devices and networks, what size files, and whether the failure is immediate or after a delay. Then check the likely causes in order of frequency: a request timeout shorter than a slow upload needs; a server or proxy body-size limit rejecting large files with a confusing status; the connection dropping as the device switches between wifi and cellular; and the tab being backgrounded mid-upload, which throttles or suspends the request. Instrument it — log the failure mode, size, duration and connection type — because "sometimes fails" is not actionable and the fix differs per cause. Mitigations: chunked and resumable uploads, client-side compression before sending, an explicit progress indicator so users do not navigate away, and a clear retry that does not restart from zero.

The habit being tested is getting specifics before theorising, because "sometimes fails" has at least four unrelated causes and each has a different fix — a timeout, a proxy body limit, a network handover and a backgrounded tab look identical from a support ticket. Instrumenting the failure is what converts it into a decidable question. The mobile-specific causes are the ones desktop-centric debugging misses entirely, since neither reproduces on a developer machine on wifi.

Why does it matter to the FRONTEND which status code an API returns?

Because the client branches on it, and a wrong code produces wrong behaviour. A 401 should trigger a re-authentication flow; a 403 should not, because retrying with the same identity will fail again. A 404 is usually a page-level empty state; a 500 is a retryable error with a "try again" affordance; a 429 carries `Retry-After` and should back off rather than hammer. An API that returns 200 with `{ error: true }` breaks all of this — `res.ok` is true, error-handling middleware never fires, caches store the failure as a success, and monitoring shows a healthy service. So status codes are the contract that lets generic client logic do the right thing without special-casing every endpoint.

The reason this is a frontend concern is that the status code is the contract the client branches on. Collapsing everything to 200 with an error in the body forces every caller to parse the body to find out whether it succeeded, which defeats caching, retry policies and error monitoring at once. The 401-versus-403 distinction is the one most often wrong, and it decides whether retrying can possibly help.