Why structured responses matter in FastAPI - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to return a JSON response with FastAPI.

FastAPI

from fastapi import FastAPI

app = FastAPI()

@app.get("/items/{item_id}")
async def read_item(item_id: int):
    return [1]

Drag options to blanks, or click blank then click option'

A{"item_id": item_id}

Bdict(item_id=item_id)

C[item_id]

Ditem_id

Attempts:

3 left

💡 Hint

Common Mistakes

Returning just the variable without a key

Returning a list instead of a dictionary

FastAPI expects a dictionary or Pydantic model to return structured JSON responses.

2fill in blank

medium

Complete the code to define a Pydantic model for structured response.

FastAPI

from pydantic import BaseModel

class Item(BaseModel):
    name: str
    price: float

@app.get("/items/{item_id}", response_model=Item)
async def read_item(item_id: int):
    return [1]

Drag options to blanks, or click blank then click option'

AItem(name="Apple", price=1.2)

B{"name": "Apple", "price": 1.2}

Cdict(name="Apple", price=1.2)

D["Apple", 1.2]

Attempts:

3 left

💡 Hint

Common Mistakes

Returning a plain dictionary instead of the model instance

Returning a list instead of an object

Returning an instance of the Pydantic model ensures the response matches the declared schema.

3fill in blank

hard

Fix the error in the response to ensure consistent JSON structure.

FastAPI

from fastapi import FastAPI

app = FastAPI()

@app.get("/users/{user_id}")
async def read_user(user_id: int):
    if user_id == 1:
        return {"name": "Alice", "age": 30}
    else:
        return [1]

Drag options to blanks, or click blank then click option'

A["User not found"]

B"User not found"

C{"error": "User not found"}

DNone

Attempts:

3 left

💡 Hint

Common Mistakes

Returning a plain string or list breaks JSON structure

Returning None causes errors

Returning a dictionary with an error key keeps the response structure consistent.

4fill in blank

hard

Fill both blanks to create a consistent response with status code and message.

FastAPI

from fastapi import FastAPI
from fastapi.responses import JSONResponse

app = FastAPI()

@app.get("/status")
async def get_status():
    return JSONResponse(content=[1], status_code=[2])

Drag options to blanks, or click blank then click option'

A{"status": "ok"}

B200

C404

D{"error": "Not found"}

Attempts:

3 left

💡 Hint

Common Mistakes

Using a string instead of dictionary for content

Using wrong status codes for success

Use a dictionary for content and a valid HTTP status code for status_code.

5fill in blank

hard

Fill all three blanks to define a Pydantic model and return it in the response.

FastAPI

from pydantic import BaseModel
from fastapi import FastAPI

app = FastAPI()

class [1](BaseModel):
    title: str
    completed: bool

@app.get("/tasks/{task_id}", response_model=[2])
async def read_task(task_id: int):
    return [3](title="Learn FastAPI", completed=False)

Drag options to blanks, or click blank then click option'

ATask

DItem

Attempts:

3 left

💡 Hint

Common Mistakes

Using different names for model and response_model

Returning a dictionary instead of model instance

Define a model named Task and use it as the response_model and return its instance.

Practice

1. Why is it important to use structured responses in FastAPI APIs?

easy

A. They allow the API to ignore validation rules.

B. They slow down the API response time significantly.

C. They make the API responses clear and predictable for users.

D. They prevent the API from generating documentation.

Solution

1. Step 1: Understand the role of structured responses

   Structured responses define a clear format for API outputs, making them predictable.

2. Step 2: Recognize benefits in FastAPI

   FastAPI uses structured responses to validate data and generate helpful docs automatically.

3. Final Answer:

   They make the API responses clear and predictable for users. -> Option C

4. Quick Check:

   Structured responses = clear, predictable API outputs [OK]

Hint: Structured responses ensure clarity and predictability [OK]

Common Mistakes:

• Thinking structured responses slow down APIs
• Believing they disable validation
• Assuming they block documentation generation

2. Which of the following is the correct way to declare a structured response model in FastAPI using Pydantic?

easy

A. class ResponseModel(BaseModel): name: str; age: int

B. def ResponseModel(name: str, age: int): return dict

C. ResponseModel = {'name': str, 'age': int}

D. class ResponseModel: name = str; age = int

Solution

1. Step 1: Identify correct Pydantic model syntax

   Pydantic models inherit from BaseModel and define fields with type annotations.

2. Step 2: Compare options

   class ResponseModel(BaseModel): name: str; age: int correctly defines a class inheriting BaseModel with typed fields; others do not follow Pydantic syntax.

3. Final Answer:

   class ResponseModel(BaseModel): name: str; age: int -> Option A

4. Quick Check:

   Pydantic model = class with BaseModel and typed fields [OK]

Hint: Use class with BaseModel and type hints for responses [OK]

Common Mistakes:

• Defining response as a plain dict
• Using functions instead of classes
• Missing BaseModel inheritance

3. Given this FastAPI endpoint:

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class User(BaseModel):
    id: int
    name: str

@app.get('/user', response_model=User)
async def get_user():
    return {'id': 1, 'name': 'Alice', 'extra': 'ignored'}

What will the API response contain?

medium

A. An error because of the extra field

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

C. {"id": 1, "name": "Alice", "extra": "ignored"}

D. {"name": "Alice"}

Solution

1. Step 1: Understand response_model filtering

   FastAPI uses the response_model to filter and validate returned data, ignoring extra fields.

2. Step 2: Analyze returned dictionary

   The returned dict has 'id', 'name', and 'extra'. 'extra' is not in User model, so it is excluded.

3. Final Answer:

   {"id": 1, "name": "Alice"} -> Option B

4. Quick Check:

   response_model filters extra fields = filtered output [OK]

Hint: response_model excludes extra fields automatically [OK]

Common Mistakes:

• Expecting extra fields to appear in response
• Thinking extra fields cause errors
• Ignoring response_model filtering

4. What is wrong with this FastAPI endpoint code?

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Item(BaseModel):
    name: str
    price: float

@app.get('/item', response_model=Item)
async def read_item():
    return {'name': 'Book'}

medium

A. The endpoint function must not be async.

B. The response_model should not be used with GET requests.

C. The class Item should not inherit from BaseModel.

D. The returned dictionary is missing the 'price' field required by Item.

Solution

1. Step 1: Check required fields in response_model

   The Item model requires 'name' and 'price' fields, both mandatory.

2. Step 2: Verify returned data matches model

   The returned dict only has 'name', missing 'price', causing validation error.

3. Final Answer:

   The returned dictionary is missing the 'price' field required by Item. -> Option D

4. Quick Check:

   Missing required fields in response_model causes errors [OK]

Hint: Returned data must include all required response_model fields [OK]

Common Mistakes:

• Ignoring missing required fields
• Thinking response_model disallows GET
• Believing async is not allowed

5. You want to create a FastAPI endpoint that returns a list of users, each with an id and optional email. Which response model setup correctly ensures structured responses with optional fields?

hard

A. class User(BaseModel): id: int; email: Optional[str]
@app.get('/users', response_model=List[User])
async def get_users(): return [{'id':1}, {'id':2, 'email':'[e-mail]'}]

B. class User(BaseModel): id: int; email: str
@app.get('/users', response_model=List[User])
async def get_users(): return [{'id':1}, {'id':2, 'email':'[e-mail]'}]

C. class User(BaseModel): id: int
@app.get('/users', response_model=List[User])
async def get_users(): return [{'id':1}, {'id':2, 'email':'[e-mail]'}]

D. class User(BaseModel): id: int; email: Optional[str]
@app.get('/users')
async def get_users(): return [{'id':1}, {'id':2, 'email':'[e-mail]'}]

Solution

1. Step 1: Define User model with optional email

   Use Optional[str] for email to allow missing values without errors.

2. Step 2: Use response_model with List[User]

   Specify response_model=List[User] to return a list of User objects with validation.

3. Step 3: Check returned data matches model

   Returned list has users with and without email, matching the optional field definition.

4. Final Answer:

   class User(BaseModel): id: int; email: Optional[str] @app.get('/users', response_model=List[User]) async def get_users(): return [{'id':1}, {'id':2, 'email':'[e-mail]'}] -> Option A

5. Quick Check:

   Optional fields + List response_model = correct structured response [OK]

Hint: Use Optional for fields that may be missing in response [OK]

Common Mistakes:

• Not marking optional fields as Optional
• Missing response_model for list endpoints
• Returning extra fields without model support