Type-safe API response handling in Typescript - Cheat Sheet & Quick Revision

Recall & Review

beginner

What does type-safe API response handling mean in TypeScript?

It means ensuring that the data received from an API matches expected types, so your program can safely use the data without runtime errors.

beginner

How can you define the expected shape of an API response in TypeScript?

By creating an interface or type that describes the structure and types of the response data.

beginner

What is the purpose of using fetch with async/await in API calls?

It allows you to write asynchronous code that waits for the API response before continuing, making the code easier to read and handle errors.

intermediate

Why should you validate or check API response data even when using TypeScript types?

Because TypeScript types only check code at compile time, but API data comes from outside and might not match the expected types at runtime.

intermediate

What is a simple way to ensure type safety when parsing JSON from an API?

Use a function that checks the presence and type of required fields before using the data, or use libraries like zod or io-ts for runtime validation.

Which TypeScript feature helps define the expected structure of API response data?

A class

B var

C interface

D function

The interface keyword defines the shape and types of an object, perfect for API responses.

Why is it important to check API response data at runtime even with TypeScript types?

A Because runtime checks slow down the program

B Because TypeScript automatically fixes data errors

C Because API data is always correct

D Because TypeScript types only check during coding, not actual data received

TypeScript types help during development but cannot guarantee the external API sends correct data.

What does async/await do in API calls?

A Makes code wait for the API response before continuing

B Makes the API call synchronous

C Automatically validates API data

D Prevents API calls

async/await lets you write code that pauses until the API responds, making it easier to handle results.

Which library can help with runtime validation of API responses in TypeScript?

A zod

B lodash

C express

D react

zod is a popular library to check data shapes at runtime in TypeScript.

What is the first step to handle an API response type-safely?

A Call the API without checking

B Define the expected response type with an interface or type

C Ignore the response data

D Use <code>any</code> type for the response

Defining the expected type helps TypeScript understand what data to expect and catch mistakes early.

Explain how you would safely handle an API response in TypeScript from fetching data to using it.

Think about the steps from calling the API to using the data in your program.

Why is runtime validation important even if you use TypeScript types for API responses?

Consider the difference between compile-time and runtime.

Practice

1. What is the main benefit of using type-safe API response handling in TypeScript?

easy

A. It makes the API faster to respond.

B. It removes the need for testing API responses.

C. It automatically fixes bugs in the API.

D. It helps catch errors early by defining expected data shapes.

Solution

1. Step 1: Understand type safety purpose

   Type-safe handling means defining what data should look like before using it.

2. Step 2: Identify the benefit

   This helps catch mistakes early, like missing or wrong data types, before running the program.

3. Final Answer:

   It helps catch errors early by defining expected data shapes. -> Option D

4. Quick Check:

   Type safety = Early error detection [OK]

Hint: Type safety means catching errors before running code [OK]

Common Mistakes:

• Thinking type safety improves API speed
• Believing it fixes bugs automatically
• Assuming it replaces testing

2. Which TypeScript syntax correctly defines a generic function to fetch API data with a type-safe response?

easy

A. function fetchData(url: string): Promise<any> { /* ... */ }

B. function fetchData<T>(url: string): Promise<T> { /* ... */ }

C. function fetchData<T>(url: string): T { /* ... */ }

D. function fetchData(url: string): T { /* ... */ }

Solution

1. Step 1: Understand generic function syntax

   Generic functions use <T> to represent a type parameter, allowing flexible typing.

2. Step 2: Check return type for async fetch

   Fetching data returns a Promise of type T, so the return type must be Promise<T>.

3. Final Answer:

   function fetchData<T>(url: string): Promise<T> { /* ... */ } -> Option B

4. Quick Check:

   Generic + Promise = function fetchData<T>(url: string): Promise<T> { /* ... */ } [OK]

Hint: Generic fetch returns Promise of type T [OK]

Common Mistakes:

• Returning T directly instead of Promise<T>
• Missing generic <T> in function definition
• Using Promise<any> loses type safety

3. Given this TypeScript code, what will be the output?

interface User { id: number; name: string; }

async function getUser(): Promise<User> {
  return { id: 1, name: "Alice" };
}

getUser().then(user => console.log(user.name));

medium

A. { id: 1, name: "Alice" }

B. 1

C. "Alice"

D. undefined

Solution

1. Step 1: Analyze the getUser function

   It returns a Promise resolving to an object with id 1 and name "Alice".

2. Step 2: Check the then callback

   The callback logs user.name, which is "Alice".

3. Final Answer:

   "Alice" -> Option C

4. Quick Check:

   user.name = "Alice" [OK]

Hint: Promise resolves to object; log property name [OK]

Common Mistakes:

• Logging user instead of user.name
• Confusing id with name
• Expecting entire object printed

4. Identify the error in this TypeScript code for type-safe API response handling:

interface ApiResponse { success: boolean; data: string; }

async function fetchApi(): Promise<ApiResponse> {
  const response = await fetch('https://api.example.com');
  const json = await response.json();
  return json;
}

medium

A. Missing type assertion or validation for json before returning.

B. The fetch call should not use await.

C. The interface ApiResponse is missing a constructor.

D. The function should return void instead of Promise<ApiResponse>.

Solution

1. Step 1: Check how json is handled

   json is returned directly without confirming it matches ApiResponse shape.

2. Step 2: Understand type safety requirement

   TypeScript needs either a type assertion or runtime validation to ensure json fits ApiResponse.

3. Final Answer:

   Missing type assertion or validation for json before returning. -> Option A

4. Quick Check:

   Validate json shape before return [OK]

Hint: Always validate or assert API response type [OK]

Common Mistakes:

• Assuming fetch json is automatically typed
• Ignoring need for runtime checks
• Misunderstanding async/await usage

5. You want to create a type-safe function that fetches a list of users from an API and returns only users with an active status. Which approach correctly applies type-safe API response handling?

hard

A. Define interface User with 'active' boolean, fetch data as Promise, then filter users by active before returning.

B. Fetch data as Promise<any>, filter users by active without type checking, then cast to User[].

C. Define interface User without 'active', fetch data as Promise, then filter users by active.

D. Fetch data as Promise, return data without filtering to keep type safety.

Solution

1. Step 1: Define User interface including 'active' property

   To filter by active status, the User type must include an 'active' boolean field.

2. Step 2: Fetch data as Promise<User[]> and filter

   Fetching with correct type ensures type safety; filtering users by active keeps the result accurate and typed.

3. Final Answer:

   Define interface User with 'active' boolean, fetch data as Promise<User[]>, then filter users by active before returning. -> Option A

4. Quick Check:

   Correct interface + typed fetch + filter = Define interface User with 'active' boolean, fetch data as Promise, then filter users by active before returning. [OK]

Hint: Include all needed fields in interface before filtering [OK]

Common Mistakes:

• Casting any to User[] without checks
• Filtering on missing properties in interface
• Returning unfiltered data losing requirements