REST API Client

A REST API client centralizes fetch calls, status handling, parsing, and errors so UI code does not repeat it. Narrow JSON from unknown to your expected contract. Use an AbortSignal for request cancellation where the actual fetch environment supports it.

The client verifies response.ok before parsing JSON and then validates both fields. The data URL provides a deterministic HTTP-like Response without a remote server.

fetch rejects for network failures, but a 404 normally fulfills with a Response; inspect response.ok and status.

This source was compiled using TypeScript 5.8.3 with strict checking, then executed with Node.js 22.16.0. Its stdout below is the actual captured output. The core logic is runnable without a framework or a remote API; integration-specific examples appear in a separate lab when needed.

TypeScript source

type Item = { id: number; name: string };
async function getItem(url: string): Promise<Item> {
  const response = await fetch(url);
  if (!response.ok) throw new Error(`HTTP ${response.status}`);
  const value: unknown = await response.json();
  if (typeof value !== "object" || value === null || !("id" in value) || typeof value.id !== "number" || !("name" in value) || typeof value.name !== "string") throw new Error("Unexpected item");
  return { id: value.id, name: value.name };
}
getItem('data:application/json,%7B%22id%22%3A5%2C%22name%22%3A%22Notebook%22%7D')
  .then(item => console.log(item)).catch(console.error);

Verified output

{ id: 5, name: 'Notebook' }

Compile: npx tsc --strict --target es2022 --module commonjs rest-api-client.ts; run: node rest-api-client.js. For examples importing node: modules, install @types/node as a development dependency; for browser or React projects use the separate lab setup.

The client verifies response.ok before parsing JSON and then validates both fields. The data URL provides a deterministic HTTP-like Response without a remote server.

Before editing the code, predict what the output will be for one changed input. Run it and compare your prediction with the actual result.

fetch rejects for network failures, but a 404 normally fulfills with a Response; inspect response.ok and status.

Determine whether the issue belongs to the type system, a trust boundary, or actual runtime behavior before choosing a correction.

Add postItem using POST with a JSON body. Verify 201 and handle invalid input responses separately.

Record expected success and failure outcomes, run the code, and compare the observed behavior. Keep the exercise compatible with strict type checking.

The client verifies response.ok before parsing JSON and then validates both fields. The data URL provides a deterministic HTTP-like Response without a remote server.

Apply the same reasoning to the practice task, then integrate it into a real app only when the runtime and dependency setup are ready.