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.

Practice

1. What is the main purpose of using Blueprints for API versioning in Flask?

easy

A. To store user session data securely

B. To speed up the Flask server automatically

C. To organize different API versions with separate URL prefixes

D. To create database models for each API version

Solution

1. Step 1: Understand Blueprints role in Flask

   Blueprints allow grouping routes and related code logically.

2. Step 2: Connect Blueprints to API versioning

   Using url_prefix in Blueprints lets you separate API versions by URL path.

3. Final Answer:

   To organize different API versions with separate URL prefixes -> Option C

4. Quick Check:

   Blueprints + url_prefix = versioned APIs [OK]

Hint: Blueprints + url_prefix separate API versions clearly [OK]

Common Mistakes:

• Thinking Blueprints speed up the server
• Confusing Blueprints with session management
• Assuming Blueprints create database models

2. Which of the following is the correct way to create a Blueprint for API version 1 with prefix '/api/v1'?

easy

A. bp = Blueprint('api_v1', __name__, url_prefix='/api/v1')

B. bp = Blueprint('api_v1', url_prefix='/api/v1')

C. bp = Blueprint(__name__, 'api_v1', url_prefix='/api/v1')

D. bp = Blueprint('api_v1', __name__, prefix='/api/v1')

Solution

1. Step 1: Recall Blueprint constructor parameters

   Blueprint(name, import_name, url_prefix=...)

2. Step 2: Identify correct syntax

   bp = Blueprint('api_v1', __name__, url_prefix='/api/v1') uses correct order and url_prefix keyword.

3. Final Answer:

   bp = Blueprint('api_v1', __name__, url_prefix='/api/v1') -> Option A

4. Quick Check:

   Blueprint(name, __name__, url_prefix=...) correct [OK]

Hint: Blueprint needs name, __name__, and url_prefix keyword [OK]

Common Mistakes:

• Omitting __name__ parameter
• Using 'prefix' instead of 'url_prefix'
• Swapping parameter order incorrectly

3. Given this Flask app code, what URL will return 'Hello from v2!'?

from flask import Flask, Blueprint
app = Flask(__name__)

bp_v1 = Blueprint('v1', __name__, url_prefix='/api/v1')
@bp_v1.route('/hello')
def hello_v1():
    return 'Hello from v1!'

bp_v2 = Blueprint('v2', __name__, url_prefix='/api/v2')
@bp_v2.route('/hello')
def hello_v2():
    return 'Hello from v2!'

app.register_blueprint(bp_v1)
app.register_blueprint(bp_v2)

medium

A. /api/v2/hello

B. /hello

C. /v2/hello

D. /api/v1/hello

Solution

1. Step 1: Check Blueprint url_prefix for v2

   Blueprint 'v2' uses url_prefix='/api/v2'.

2. Step 2: Check route path inside v2 Blueprint

   Route is '/hello', so full path is '/api/v2/hello'.

3. Final Answer:

   /api/v2/hello -> Option A

4. Quick Check:

   Blueprint prefix + route = full URL [OK]

Hint: Combine url_prefix and route path for full URL [OK]

Common Mistakes:

• Ignoring url_prefix and using only route path
• Confusing v1 and v2 prefixes
• Assuming route is registered at root '/'

4. What is wrong with this Flask code for versioned API Blueprints?

bp_v1 = Blueprint('v1', __name__, url_prefix='/api/v1')
@bp_v1.route('/data')
def data_v1():
    return 'Data v1'

app.register_blueprint(bp_v1)

bp_v2 = Blueprint('v2', __name__, url_prefix='/api/v2')
@bp_v1.route('/data')
def data_v2():
    return 'Data v2'

app.register_blueprint(bp_v2)

medium

A. Functions cannot return strings directly

B. Blueprints cannot have the same route path

C. url_prefix should be set on app, not Blueprint

D. The second route decorator uses bp_v1 instead of bp_v2

Solution

1. Step 1: Identify route decorators and Blueprints

   The second route uses @bp_v1.route but should use @bp_v2.route.

2. Step 2: Understand impact of wrong decorator

   This causes the second function to register on the first Blueprint, not the second.

3. Final Answer:

   The second route decorator uses bp_v1 instead of bp_v2 -> Option D

4. Quick Check:

   Route decorator must match Blueprint instance [OK]

Hint: Match route decorator to correct Blueprint instance [OK]

Common Mistakes:

• Using wrong Blueprint for route decorator
• Thinking url_prefix belongs on app
• Believing functions can't return strings

5. You want to add a new API version 3 with a Blueprint and share a common route '/status' that returns different messages per version. Which approach correctly implements this in Flask?

hard

A. Define '/status' route only once on app without Blueprints and check version from headers

B. Create separate Blueprints for v1, v2, v3 each with url_prefix and define '/status' route inside each Blueprint

C. Create one Blueprint with url_prefix='/api' and use if-else inside '/status' route to check version

D. Use Flask extensions to automatically version APIs without Blueprints

Solution

1. Step 1: Understand version separation with Blueprints

   Each API version should have its own Blueprint with distinct url_prefix.

2. Step 2: Define '/status' route separately in each Blueprint

   This allows each version to return its own message cleanly and maintainably.

3. Final Answer:

   Create separate Blueprints for v1, v2, v3 each with url_prefix and define '/status' route inside each Blueprint -> Option B

4. Quick Check:

   Separate Blueprints per version = clean versioning [OK]

Hint: Use separate Blueprints per version for clean route separation [OK]

Common Mistakes:

• Trying to handle versions inside one route with if-else
• Defining routes only once without version separation
• Relying on extensions without understanding Blueprints