API versioning with routing in Nginx - Step-by-Step Execution

Process Flow - API versioning with routing

Client sends request

↓

Nginx receives request

↓

Check URL path for version

↓

/v1/*

↓

Route to v1 backend

↓

Backend processes request

↓

Response sent back to client

Nginx checks the request URL path for version info and routes to the matching backend service.

Execution Sample

Nginx

location /v1/ {
    proxy_pass http://backend_v1;
}
location /v2/ {
    proxy_pass http://backend_v2;
}

Routes requests with /v1/ to backend_v1 and /v2/ to backend_v2.

Process Table

Step	Request URL	Version Detected	Routing Action	Backend Target
1	/v1/users	/v1	Route to /v1 location block	backend_v1
2	/v2/orders	/v2	Route to /v2 location block	backend_v2
3	/v3/products	No match	Default routing or 404	No backend
4	/v1/status	/v1	Route to /v1 location block	backend_v1
5	/api/v2/data	No match	Default routing or 404	No backend

💡 Requests without matching version prefix are not routed to versioned backends.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5
Request URL		/v1/users	/v2/orders	/v3/products	/v1/status	/api/v2/data
Version Detected		/v1	/v2	No match	/v1	No match
Backend Target		backend_v1	backend_v2	No backend	backend_v1	No backend

Key Moments - 2 Insights

Why does the request to /v3/products not route to any backend?

Because the execution_table row 3 shows no version prefix match, nginx does not find a location block for /v3/, so it uses default routing or returns 404.

Why does /api/v2/data not route to backend_v2 even though it contains 'v2'?

The routing matches only if the URL path starts exactly with /v2/. Since /api/v2/data does not start with /v2/, it does not match the /v2/ location block (see execution_table row 5).

Visual Quiz - 3 Questions

Look at the execution_table, what backend does the request to /v1/status route to?

A No backend

B backend_v1

C backend_v2

D Default backend

💡 Hint

Check execution_table row 4 under Backend Target column.

At which step does the version detection fail to find a matching version prefix?

A Step 3

B Step 1

C Step 4

D Step 2

💡 Hint

Look at the Version Detected column in execution_table for 'No match'.

If we add a location block for /v3/, what would happen to the request at step 3?

A It would still return 404

B It would route to backend_v1

C It would route to backend_v3

D It would route to backend_v2

💡 Hint

Adding a matching location block routes requests to that backend (see concept_flow).

Concept Snapshot

API versioning with routing in nginx:
- Use location blocks matching version prefixes like /v1/, /v2/
- Requests matching /v1/* route to backend_v1
- Requests matching /v2/* route to backend_v2
- Requests without matching prefix use default or 404
- This cleanly separates API versions by URL path

Full Transcript

This visual execution shows how nginx routes API requests based on version prefixes in the URL path. When a client sends a request, nginx checks the URL path for version segments like /v1/ or /v2/. It then routes the request to the corresponding backend service configured in location blocks. Requests that do not match any version prefix are routed to default or return 404. The execution table traces requests step-by-step, showing detected version and backend target. The variable tracker shows how request URL, detected version, and backend target change per request. Key moments clarify why some requests do not route to any backend. The quiz tests understanding of routing decisions based on the execution visuals. This method helps maintain multiple API versions cleanly and safely.

Practice

1. What is the main purpose of using API versioning with routing in nginx?

easy

A. To block all API requests except the latest version

B. To combine all API versions into a single endpoint

C. To run multiple API versions side by side and route requests accordingly

D. To disable routing and serve static files only

Solution

1. Step 1: Understand API versioning concept

   API versioning allows different versions of an API to coexist, so clients using older versions still work.

2. Step 2: Role of nginx routing

   nginx uses location blocks to route requests to the correct API version based on the URL path.

3. Final Answer:

   To run multiple API versions side by side and route requests accordingly -> Option C

4. Quick Check:

   API versioning = multiple versions side by side [OK]

Hint: API versioning means routing requests to different versions [OK]

Common Mistakes:

• Thinking API versioning disables old versions
• Assuming all versions merge into one endpoint
• Confusing routing with blocking requests

2. Which nginx configuration snippet correctly routes requests to API version v1 at path /api/v1/?

easy

A. location /api/v1/ { proxy_pass http://backend_v1; }

B. location /api/v1 { proxy_pass http://backend_v1; }

C. location /api/v1/* { proxy_pass http://backend_v1; }

D. location /api/v1$ { proxy_pass http://backend_v1; }

Solution

1. Step 1: Understand nginx location matching

   Using location /api/v1/ matches all requests starting with /api/v1/, including subpaths.

2. Step 2: Check syntax correctness

   location /api/v1/ { proxy_pass http://backend_v1; } uses correct syntax without wildcards or regex, which nginx does not support in this form.

3. Final Answer:

   location /api/v1/ { proxy_pass http://backend_v1; } -> Option A

4. Quick Check:

   Trailing slash in location matches subpaths [OK]

Hint: Use trailing slash in location to match all subpaths [OK]

Common Mistakes:

• Using wildcards (*) in location which nginx does not support
• Missing trailing slash causing partial matches
• Using regex syntax without ~

3. Given this nginx config snippet, what backend will handle a request to /api/v2/users?

location /api/v1/ {
  proxy_pass http://backend_v1;
}
location /api/v2/ {
  proxy_pass http://backend_v2;
}

medium

A. http://backend_v2

B. No backend, 404 error

C. http://backend_v1

D. Both backends in round-robin

Solution

1. Step 1: Match request path to location blocks

   The request path /api/v2/users starts with /api/v2/, so it matches the second location block.

2. Step 2: Determine proxy backend

   The matching location proxies to http://backend_v2, so this backend handles the request.

3. Final Answer:

   http://backend_v2 -> Option A

4. Quick Check:

   Request path prefix matches location prefix [OK]

Hint: Match URL prefix to location prefix to find backend [OK]

Common Mistakes:

• Choosing backend_v1 for /api/v2/ path
• Assuming nginx load balances both backends automatically
• Thinking unmatched paths cause proxy to backend_v1

4. Identify the error in this nginx config for API versioning:

location /api/v1 {
  proxy_pass http://backend_v1;
}
location /api/v2/ {
  proxy_pass http://backend_v2;
}

medium

A. proxy_pass must use IP address, not hostname

B. proxy_pass URLs must include trailing slash

C. location blocks cannot be adjacent

D. Missing trailing slash in first location causes incorrect routing

Solution

1. Step 1: Check location path consistency

   The first location uses /api/v1 without trailing slash, which matches only exact path or prefix differently than /api/v1/.

2. Step 2: Understand routing impact

   Requests like /api/v1/users won't match the first location correctly, causing routing errors.

3. Final Answer:

   Missing trailing slash in first location causes incorrect routing -> Option D

4. Quick Check:

   Trailing slash in location matters for prefix matching [OK]

Hint: Always use trailing slash in location for API version prefixes [OK]

Common Mistakes:

• Ignoring trailing slash difference in location paths
• Thinking proxy_pass URL must have trailing slash
• Believing location blocks cannot be next to each other

5. You want to support API versions v1 and v2 in nginx, but also redirect any request to /api/ without version to v2 by default. Which config snippet achieves this correctly?

hard

A. location /api/ { proxy_pass http://backend_v2; }
location /api/v1/ { proxy_pass http://backend_v1; }

B. location /api/v1/ { proxy_pass http://backend_v1; }
location /api/v2/ { proxy_pass http://backend_v2; }
location /api/ { return 301 /api/v2/; }

C. location /api/ { proxy_pass http://backend_v1; }
location /api/v2/ { proxy_pass http://backend_v2; }

D. location /api/v1/ { proxy_pass http://backend_v1; }
location /api/v2/ { proxy_pass http://backend_v2; }
location /api/ { proxy_pass http://backend_v2; }

Solution

1. Step 1: Define explicit version locations

   Locations for /api/v1/ and /api/v2/ proxy requests to respective backends.

2. Step 2: Redirect base /api/ to default version

   Using return 301 /api/v2/; in /api/ location sends clients to v2 URL, ensuring default version usage.

3. Final Answer:

   location /api/v1/ { proxy_pass http://backend_v1; } location /api/v2/ { proxy_pass http://backend_v2; } location /api/ { return 301 /api/v2/; } -> Option B

4. Quick Check:

   Redirect base path to default version with return 301 [OK]

Hint: Use return 301 to redirect base API path to default version [OK]

Common Mistakes:

• Proxying /api/ directly instead of redirecting
• Overlapping location blocks causing conflicts
• Using proxy_pass in /api/ without redirect