What is it?
fetch is the browser's built-in HTTP client. Give it a URL, get a
promise that resolves to a Response. Read the body as JSON, text, or a
stream. Error handling is where most code goes wrong — fetch only
rejects on network errors, not on 404s or 500s.
Why it matters
Talking to an API is half the job. Code that handles errors thoughtfully — retries, user-facing messages, telemetry — is the difference between "works on my laptop" and shipping. Hiring managers ask "what happens when the API is down?" and listen carefully.
What to learn
fetch(url, options)— method, headers, body, credentials- The
Responseobject:.ok,.status,.json(),.text() - Why
fetchdoesn't throw on 4xx / 5xx (and how to handle them yourself) - Aborting requests with
AbortController - Headers:
Content-Type,Authorization, custom headers - Error categories: network, parse, application — handle each separately
Common pitfall
Calling .json() without checking response.ok first. A 500 error has
a JSON body that might or might not parse, but treating it as success
sends garbage downstream. Always: if (!response.ok) throw new Error(...)
before parsing.
Resources
Primary (free):
- MDN — Using Fetch · docs
- web.dev — Network requests · docs
- JavaScript.info — Fetch · docs
Practice
Build a small client that calls a public API (GitHub's user endpoint). Handle these four cases distinctly: 200 OK, 404 not found, 500 server error, and network failure (turn off Wi-Fi mid-request). Each case should log a different message and never crash the page. Done when all four are handled and the UI never breaks.
Outcomes
- Make a fetch call with proper error handling without copying boilerplate.
- Distinguish network errors from API errors from parsing errors.
- Cancel an in-flight request when the user navigates away.
- Read a real API response and pick the right
.json()vs.text()path.