REST API serving with FastAPI in MLOps - Step-by-Step Execution

Process Flow - REST API serving with FastAPI

Start FastAPI app

↓

Receive HTTP request

↓

Match request path & method

↓

Call corresponding function

↓

Process input data

↓

Generate response data

↓

Send HTTP response

↓

Wait for next request

This flow shows how FastAPI starts, receives a request, matches it to a function, processes data, and sends back a response.

Execution Sample

MLOps

from fastapi import FastAPI
app = FastAPI()

@app.get("/hello")
def say_hello():
    return {"message": "Hello, world!"}

This code creates a FastAPI app with one GET endpoint '/hello' that returns a greeting message.

Process Table

Step	Action	Input	Function Called	Output	Response Sent
1	Start FastAPI app	N/A	N/A	App running on localhost:8000	N/A
2	Receive HTTP GET request	GET /hello	say_hello()	Returns {"message": "Hello, world!"}	HTTP 200 with JSON body
3	Send response	N/A	N/A	Response sent to client	Client receives JSON message
4	Wait for next request	N/A	N/A	Idle, listening	N/A

💡 No exit; server runs continuously waiting for requests.

Status Tracker

Variable	Start	After Request 1	After Request 2	Final
app	FastAPI instance created	Running	Running	Running
request	None	GET /hello	GET /hello	Depends on incoming requests
response	None	{"message": "Hello, world!"}	{"message": "Hello, world!"}	Depends on function output

Key Moments - 3 Insights

Why does the function say_hello() not take any parameters?

Because the endpoint '/hello' does not require any input data, so FastAPI calls say_hello() without arguments as shown in execution_table step 2.

How does FastAPI know which function to call for the GET /hello request?

FastAPI matches the HTTP method and path to the decorated function @app.get('/hello'), as shown in the flow and execution_table step 2.

Why does the server keep running after sending the response?

Because FastAPI is designed to serve multiple requests continuously, it waits for new requests after sending each response, as shown in execution_table step 4.

Visual Quiz - 3 Questions

Look at the execution table, what is the output of the function say_hello() at step 2?

A Empty response

B HTTP 404 Not Found

C {"message": "Hello, world!"}

D Error message

💡 Hint

Check the 'Output' column in execution_table row for step 2.

At which step does the server send the HTTP response back to the client?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look for 'Send response' action in execution_table.

If you add a POST endpoint, how would the execution_table change?

A Add new rows for POST requests with corresponding function calls

B Replace GET /hello with POST /hello

C Remove step 4

D No change needed

💡 Hint

Consider how new request types appear in execution_table rows.

Concept Snapshot

FastAPI creates a web server to handle HTTP requests.
Use @app.get('/path') to define GET endpoints.
Functions return data that FastAPI sends as JSON responses.
Server runs continuously, waiting for requests.
No parameters needed if endpoint has no input.

Full Transcript

This visual execution shows how FastAPI serves a REST API. First, the FastAPI app starts and listens on a port. When a client sends a GET request to '/hello', FastAPI matches this to the say_hello() function. The function returns a JSON message. FastAPI sends this response back to the client with HTTP status 200. After sending, the server waits for more requests. Variables like app, request, and response change state during this process. Key points include how FastAPI matches routes to functions and why the server keeps running. The quiz tests understanding of outputs, response timing, and adding new endpoints.

Practice

1. What is the main purpose of using FastAPI in serving machine learning models?

easy

A. To train machine learning models faster

B. To create fast and simple REST APIs for model serving

C. To store large datasets efficiently

D. To visualize model performance graphs

Solution

1. Step 1: Understand FastAPI's role

   FastAPI is a web framework used to build APIs quickly and simply.

2. Step 2: Connect to model serving

   It is commonly used to serve machine learning models via REST APIs for easy access.

3. Final Answer:

   To create fast and simple REST APIs for model serving -> Option B

4. Quick Check:

   FastAPI = REST API serving [OK]

Hint: FastAPI is for building APIs, not training or storage [OK]

Common Mistakes:

• Confusing API serving with model training
• Thinking FastAPI handles data storage
• Assuming FastAPI is for visualization

2. Which of the following is the correct way to define a GET endpoint in FastAPI?

easy

A. @app.route('/items', method='GET')
def read_items():
return {'items': []}

B. @app.post('/items')
def read_items():
return {'items': []}

C. @app.get('/items')
def read_items():
print('items')

D. @app.get('/items')
def read_items():
return {'items': []}

Solution

1. Step 1: Identify correct decorator for GET

   FastAPI uses @app.get() to define GET endpoints.

2. Step 2: Check function returns JSON response

   The function should return a dictionary to send JSON; print statement does not return data.

3. Final Answer:

   @app.get('/items')\ndef read_items():\n return {'items': []} -> Option D

4. Quick Check:

   @app.get() + return dict = correct GET endpoint [OK]

Hint: Use @app.get() and return dict for GET endpoints [OK]

Common Mistakes:

• Using @app.post() for GET endpoints
• Using print instead of return
• Using Flask-style @app.route() syntax

3. What will be the output when you call the following FastAPI endpoint?

@app.get('/hello')
def say_hello():
    return {'message': 'Hello, FastAPI!'}

medium

A. {\"message\": \"Hello, FastAPI!\"}

B. Hello, FastAPI!

C. Error: Missing return type

D. 404 Not Found

Solution

1. Step 1: Analyze endpoint return value

   The function returns a dictionary with key 'message' and value 'Hello, FastAPI!'.

2. Step 2: Understand FastAPI response format

   FastAPI automatically converts dict to JSON response with the same structure.

3. Final Answer:

   {"message": "Hello, FastAPI!"} -> Option A

4. Quick Check:

   Return dict = JSON response with same keys [OK]

Hint: Return dict from endpoint gives JSON response [OK]

Common Mistakes:

• Expecting plain string instead of JSON
• Thinking missing return type causes error
• Assuming endpoint path is incorrect

4. Identify the error in this FastAPI POST endpoint code:

@app.post('/predict')
def predict(data: dict):
    return {'result': data['value'] * 2}

medium

A. Missing request body declaration with Pydantic model

B. Incorrect HTTP method, should be GET

C. Function missing return statement

D. Syntax error in decorator

Solution

1. Step 1: Check parameter type for POST data

   FastAPI requires request body to be declared with Pydantic models or Body for parsing JSON.

2. Step 2: Understand why dict alone is insufficient

   Using plain dict as parameter does not parse JSON body automatically, causing validation error.

3. Final Answer:

   Missing request body declaration with Pydantic model -> Option A

4. Quick Check:

   POST body needs Pydantic model or Body [OK]

Hint: Use Pydantic models for POST request bodies [OK]

Common Mistakes:

• Using plain dict instead of Pydantic model
• Confusing POST with GET method
• Forgetting to return a response

5. You want to serve a machine learning model prediction via FastAPI. Which approach correctly handles input validation and prediction?

from pydantic import BaseModel

class InputData(BaseModel):
    feature1: float
    feature2: float

@app.post('/predict')
def predict(data: InputData):
    result = model.predict([[data.feature1, data.feature2]])
    return {'prediction': result[0]}

What is the main advantage of this design?

hard

A. It skips input validation for faster response

B. It trains the model on each request

C. It validates input data types automatically before prediction

D. It returns raw model object instead of prediction

Solution

1. Step 1: Understand Pydantic model role

   InputData class validates that feature1 and feature2 are floats before function runs.

2. Step 2: Connect validation to prediction safety

   This prevents invalid data from reaching model.predict, avoiding runtime errors.

3. Final Answer:

   It validates input data types automatically before prediction -> Option C

4. Quick Check:

   Pydantic = automatic input validation [OK]

Hint: Use Pydantic models to validate inputs before prediction [OK]

Common Mistakes:

• Thinking model retrains on each request
• Skipping validation causes errors
• Returning model object instead of prediction