API versioning with blueprints in Flask - Step-by-Step Execution

Concept Flow - API versioning with blueprints

Start Flask App

↓

Define Blueprint v1

↓

Define Blueprint v2

↓

Register Blueprints with URL prefixes

↓

Client sends request

↓

Request routed to correct blueprint based on URL

↓

Return versioned API response

↓

End

This flow shows how Flask uses blueprints to separate API versions and route requests based on URL prefixes.

Execution Sample

Flask

from flask import Flask, Blueprint

v1 = Blueprint('v1', __name__, url_prefix='/api/v1')

@v1.route('/hello')
def hello_v1():
    return 'Hello from v1!'

app = Flask(__name__)
app.register_blueprint(v1)

Defines a blueprint for API version 1 and registers it with the Flask app under '/api/v1'.

Execution Table

Step	Action	URL Accessed	Blueprint Routed	Response
1	Start Flask app	-	-	-
2	Define blueprint v1 with prefix '/api/v1'	-	-	-
3	Register blueprint v1 to app	-	-	-
4	Client sends GET request to '/api/v1/hello'	/api/v1/hello	v1	Hello from v1!
5	Client sends GET request to '/api/v2/hello'	/api/v2/hello	No matching blueprint	404 Not Found

💡 Requests outside registered blueprint prefixes return 404; app stops after handling requests.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5
app.blueprints	{}	{}	{'v1': Blueprint}	{'v1': Blueprint}	{'v1': Blueprint}
request URL	-	-	-	/api/v1/hello	/api/v2/hello
routed blueprint	-	-	-	v1	None
response	-	-	-	'Hello from v1!'	'404 Not Found'

Key Moments - 2 Insights

Why does accessing '/api/v2/hello' return 404?

Because only the 'v1' blueprint is registered with prefix '/api/v1'. No blueprint handles '/api/v2', so Flask returns 404. See execution_table row 5.

How does Flask know which blueprint to use for a request?

Flask matches the request URL prefix to the blueprint's url_prefix. The blueprint with matching prefix handles the request. See execution_table rows 4 and 5.

Visual Quiz - 3 Questions

Look at the execution table, which blueprint handles the request to '/api/v1/hello'?

A No blueprint

B v2

C v1

D Both v1 and v2

💡 Hint

Check the 'Blueprint Routed' column at step 4 in the execution_table.

At which step does the app register the blueprint 'v1'?

A Step 3

B Step 2

C Step 1

D Step 4

💡 Hint

Look at the 'Action' column in the execution_table for blueprint registration.

If you add a blueprint 'v2' with prefix '/api/v2', what will happen when accessing '/api/v2/hello'?

A Return 404 Not Found

B Route to v2 blueprint

C Route to v1 blueprint

D Server error

💡 Hint

Refer to how Flask routes requests based on url_prefix in the variable_tracker and execution_table.

Concept Snapshot

API versioning with Flask blueprints:
- Create a Blueprint for each API version.
- Use url_prefix to set version path (e.g., '/api/v1').
- Register each blueprint with the Flask app.
- Requests route to blueprint matching URL prefix.
- Unmatched URLs return 404.
This cleanly separates API versions in one app.

Full Transcript

This lesson shows how to use Flask blueprints to manage API versioning. We start by creating a Flask app and defining a blueprint named 'v1' with the URL prefix '/api/v1'. We add a route '/hello' inside this blueprint that returns a simple greeting. Then, we register this blueprint with the Flask app. When a client sends a request to '/api/v1/hello', Flask routes it to the 'v1' blueprint and returns the greeting. If the client requests '/api/v2/hello', Flask finds no matching blueprint and returns a 404 error. This method helps organize different API versions clearly and keeps code clean. The execution table tracks each step, showing how requests are routed and responses returned. The variable tracker shows how the app's blueprints and request URLs change over time. Key moments clarify why unmatched URLs return 404 and how Flask matches URLs to blueprints. The quiz tests understanding of blueprint routing and registration steps. The snapshot summarizes the main points for quick review.