How does the fetch API work? | Interview Question

Q: How does the fetch API work?

**Target Audience:** Engineers preparing for JavaScript/browser-API interviews. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every request below was actually made against a real local HTTP server spun up for this verification, not simulated. ## 1. Why This Even Matters — A Story First Calling a delivery company to ask "did my package arrive?" — the phone call itself succeeding (someone answers) is a completely separate thing from the ANSWER being good news. `fetch`'s Promise resolving is exactly like the call being successfully answered — it tells you the network conversation itself completed. Whether the actual news is good (200 OK) or bad (404 Not Found) is a second, separate thing you have to explicitly check by looking at what they actually said, not by whether the call connected at all. ## 2. The Core Idea 📌 **Interview term:** `fetch()` returns a Promise that resolves for

01

Understand the problem

Question presented to candidate: "If a fetch() call gets back a 404 response from the server, does the returned Promise reject or resolve? Walk me through exactly how you'd correctly handle that case."

What a strong answer should cover:

📌 Interview term: fetch(url, options) — the standard, Promise-based API for making HTTP requests, returning a Promise that resolves to a Response object.
📌 Interview term: the real, direct answer to the prompt — verified directly against a real local server: a genuine 404 response resolves the fetch Promise, not rejects it — response.ok is genuinely false and response.status is genuinely 404, but no error is thrown and no .catch() runs. A precise answer names that correctly handling this requires an explicit check of response.ok (or the specific status code) after the await/.then(), not a try/catch alone.
📌 Interview term: when fetch actually DOES reject — verified directly: only a genuine network-level failure (DNS failure, connection refused, no server listening at all) genuinely rejects the Promise, with a real TypeError — a real, sharp distinction from an HTTP-level error response.
A precise answer names the real steps to read a response body: response.json()/response.text()/response.blob() are themselves also Promise-returning methods (reading the body is an async operation), verified directly with a real JSON body parsed correctly.
A precise answer names that fetch accepts a second options object for method, headers, and body — verified directly with a real POST request carrying a JSON body and a Content-Type header.

Clarifying questions expected:

None — this is a definitional/technical question; directly answering the prompt's own 404-resolves-not-rejects question is the strong signal, since it is the single most commonly misunderstood detail about fetch.

Code / implementation expected: Yes — a real fetch call against a real 404 endpoint, directly observing that it resolves rather than rejects, is the clearest, most convincing demonstration.

fetch

02

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Nudge consolestandby

Stuck? Beam a request up — the console returns a conceptual nudge that guides your logic without spoiling the implementation.

03

Study the solution

Target Audience: Engineers preparing for JavaScript/browser-API interviews. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every request below was actually made against a real local HTTP server spun up for this ve

Solution ready — 2 min read

Classified // press E to declassify

04

Run the code

JSReal proof, against a real live server: a 404 resolves the fetch Promise (check response.ok), only a network failure genuinely rejects

Practice

05

Join the discussion

Discussion (0)

Sign in to join the discussion.

No responses yet. Be the first to share what you think.