Unit Project: Resilient API Client

COMPLETE LESSON · ABOUT 65 MIN OF ACTIVE PRACTICE

Learn Unit Project: Resilient API Client step by step

Follow the lesson in order: understand the model, trace worked examples, run a controlled experiment, debug a faulty assumption, build independently, and verify your reasoning.

LESSON MAP

What you will understand and apply

Model idle, pending, success, empty, and failure
Abort obsolete requests and protect against stale results
Test with injected deterministic response doubles
Build a resilient search or weather client with validated JSON, cancellation, timeout, retry, accessible status, and deterministic tests.

DEEP EXPLANATION

Build the complete mental model

Build the mental model

Define the state machine before the interface: idle has no query, pending identifies the active request, success owns validated data, empty is a valid response with no records, and failure carries a safe message plus retry action. Cancellation is expected control flow when a newer query replaces old work and should not appear as an alarming error. Before writing more syntax, name the values involved in Unit Project: Resilient API Client, who creates them, and which result or effect the program promises. Trace the smallest example by hand and identify any browser or runtime API separately from the language feature. A useful mental model should predict a changed input, not merely describe the demonstration after it runs.

Use the API deliberately

Put transport behavior in requestJson, response-shape validation in a separate function, and DOM rendering in the interface layer. Give each request a controller or sequence identity so an obsolete result cannot replace current state. A timeout can abort work, but retries need limits, backoff, and rules that avoid repeating unsafe operations. During implementation, keep the AbortController rule in a focused function or event boundary with explicit inputs. Choose names that reveal the domain, keep calculation separate from document, console, storage, or network effects, and prefer the narrowest API that expresses the problem. Compare this design with one reasonable alternative and explain why the selected construct makes ownership or control flow clearer.

Handle boundaries and tradeoffs

Do not depend on a public live API for tests. Inject a fetch-compatible function that returns controlled success, HTTP failure, invalid JSON shape, slow settlement, and AbortError. Verify that status text is visible and announced, the retry action preserves the query, and rapid query changes never render stale data. Verification for Unit Project: Resilient API Client must cover an ordinary case, an empty or missing case, invalid input, and the most important threshold. Predict each result before running it, then locate the first value that violates the contract when reality differs. Record the corrected case as a repeatable check and explain which product behavior should occur instead of allowing undefined, NaN, stale data, or silent failure to spread.

WORKED EXAMPLES

Read the decision before the syntax

Example 1: Project foundation

Trace this Unit Project: Resilient API Client example from validated input to returned value or visible effect before editing it.

let activeController;
async function requestLatest(url, fetcher = fetch) {
  activeController?.abort();
  const controller = new AbortController();
  activeController = controller;
  const response = await fetcher(url, { signal: controller.signal });
  if (!response.ok) throw new Error(`Request failed (${response.status})`);
  const data = await response.json();
  if (!data || typeof data !== "object") throw new TypeError("Unexpected response");
  return data;
}
console.log("Inject a mock fetcher to test success and failure without network access.");

Example 2: Second worked example

This variation changes the shape of the problem so you can compare the underlying AbortController contract instead of copying one solution.

function createMockResponse({ status = 200, data = {} } = {}) {
  return Promise.resolve({
    ok: status >= 200 && status < 300,
    status,
    headers: new Headers({ "content-type": "application/json" }),
    json: async () => data,
  });
}
requestLatest("/practice", () => createMockResponse({ data: { temperature: 24 } })).then(console.log);

How to trace this lesson

Write down the exact inputs used by Unit Project: Resilient API Client.
Predict each returned value and observable effect before running the example.
Mark the first boundary where invalid or missing data could enter.
Verify the ordinary, empty, invalid, and threshold cases independently.

Common mistakes and corrections

Rendering whichever request finishes last can show an old query after the learner has already requested a newer one.: Make the AbortController rule explicit and cover it with a focused example.
Changing several parts of the example before explaining the original result.: Make one change at a time and compare it with a written prediction.
Testing only the demonstration's happy path.: Add missing, invalid, empty, and boundary inputs that exercise the stated contract.

PRACTICE LADDER

Move from recognition to independent work

1
Model idle, pending, success, empty, and failure
2
Abort obsolete requests and protect against stale results
3
Test with injected deterministic response doubles
4
Build a resilient search or weather client with validated JSON, cancellation, timeout, retry, accessible status, and deterministic tests.

Complete these in order. The final step should work without copying the lesson example; use the runner and lab below to test it.

Core rule

Applied boundary

RUNNABLE EXAMPLE

Change one assumption at a time

Predict the output, run the example, then change one input and one boundary in the Unit Project: Resilient API Client example. Explain every changed result before continuing.

let activeController;
async function requestLatest(url, fetcher = fetch) {
  activeController?.abort();
  const controller = new AbortController();
  activeController = controller;
  const response = await fetcher(url, { signal: controller.signal });
  if (!response.ok) throw new Error(`Request failed (${response.status})`);
  const data = await response.json();
  if (!data || typeof data !== "object") throw new TypeError("Unexpected response");
  return data;
}
console.log("Inject a mock fetcher to test success and failure without network access.");

let activeController;
async function requestLatest(url, fetcher = fetch) {
  activeController?.abort();
  const controller = new AbortController();
  activeController = controller;
  const response = await fetcher(url, { signal: controller.signal });
  if (!response.ok) throw new Error(`Request failed (${response.status})`);
  const data = await response.json();
  if (!data || typeof data !== "object") throw new TypeError("Unexpected response");
  return data;
}
console.log("Inject a mock fetcher to test success and failure without network access.");

Press Run to execute your code.

DEBUGGING CHALLENGE

Locate the first incorrect value

Predict the failure and write your repair before revealing the explanation.

const data = await fetch(url).then(response => response.json());

Reveal repair and explanation

const response = await fetch(url, { signal });
if (!response.ok) throw new Error(`HTTP ${response.status}`);
const data = await response.json();

A fulfilled fetch can still be an HTTP failure, and cancellation requires passing the signal into the request.

INDEPENDENT LAB

Build without copying the example

Build a resilient search or weather client with validated JSON, cancellation, timeout, retry, accessible status, and deterministic tests.

// Define small functions before composing the complete solution.
// Build a resilient search or weather client with validated JSON, cancellation, timeout, retry, accessible status, and deterministic tests.

// Define small functions before composing the complete solution.
// Build a resilient search or weather client with validated JSON, cancellation, timeout, retry, accessible status, and deterministic tests.

Press Run to execute your code.

Self-review checklist Model idle, pending, success, empty, and failure Abort obsolete requests and protect against stale results Test with injected deterministic response doublesWhat did you predict, observe, and change?

KNOWLEDGE CHECK

Explain the rule, not only the syntax

1. How can an interface prevent an older request from replacing newer results? Abort or identify obsolete requests Add innerHTML around the response Remove all error states

2. Which evidence best demonstrates mastery of Unit Project: Resilient API Client? A prediction, boundary tests, and an explained result A copied snippet with no changes One successful happy-path run

Loading saved work…

Code and answers save automatically. Guest work stays on this device; signed-in work syncs to your account. The runner is isolated, blocks network access, and stops long-running console programs.

Unit Project: Resilient API Client | JavaScript Course | SovranCode

1. JavaScript Foundations

2. Functions and Collections

3. Objects and Structured Data

4. Browser Interfaces

5. Async and Reliable Applications

6. Application Engineering