API versioning with routing in Nginx - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of NGINX routing for API version v1

Given the following NGINX configuration snippet, what will be the response status code when a client requests /api/v1/users?

Nginx

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

A 200 OK from backend_v1

B 404 Not Found

C 502 Bad Gateway

D 301 Moved Permanently

💡 Hint

Check which location block matches the requested URI.

The request URI /api/v1/users matches the location /api/v1/ which proxies to backend_v1. Assuming backend_v1 is healthy, the response is 200 OK.

❓ Configuration

intermediate

Correct NGINX config for API versioning with header

Which NGINX configuration snippet correctly routes requests to different backends based on the custom header X-API-Version with values v1 or v2?

A

server {
    listen 80;
    location /api/ {
        proxy_pass http://backend_v1/;
        if ($http_x_api_version = 'v2') {
            proxy_pass http://backend_v2/;
        }
    }
}

B

map $http_x_api_version $backend {
    default backend_v1;
    v2 backend_v2;
}
server {
    listen 80;
    location /api/ {
        proxy_pass http://$backend/;
    }
}

C

server {
    listen 80;
    if ($http_x_api_version = 'v2') {
        proxy_pass http://backend_v2/;
    }
    location /api/ {
        proxy_pass http://backend_v1/;
    }
}

D

server {
    listen 80;
    location /api/ {
        proxy_pass http://backend_v1/;
    }
    location /api/v2/ {
        proxy_pass http://backend_v2/;
    }
}

💡 Hint

Use the map directive to select backend based on header.

Option B uses the map directive to assign the backend based on the X-API-Version header, then proxies accordingly. Other options misuse if or location blocks.

❓ Troubleshoot

advanced

Troubleshoot NGINX API version routing failure

A user reports that requests to /api/v2/orders always return 404 Not Found, but /api/v1/orders works fine. Given this NGINX config, what is the most likely cause?

Nginx

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

A proxy_pass URL missing trailing slash in /api/v1 location

B backend_v2 is down causing 404 errors

C Missing trailing slash in location /api/v2 causes URI mismatch

D NGINX does not support multiple location blocks with similar prefixes

💡 Hint

Check how NGINX matches location blocks and rewrites URIs with proxy_pass.

The location /api/v2 lacks a trailing slash, so NGINX does not rewrite the URI correctly, causing 404 errors. Adding a trailing slash fixes the issue.

🔀 Workflow

advanced

Order of NGINX location blocks for API versioning

Given these location blocks, what is the correct order to ensure requests to /api/v2/users route to the v2 backend and /api/users route to the default backend?

A 1,3,2

B 2,3,1

C 3,1,2

D 1,2,3

💡 Hint

More specific location blocks must come before less specific ones.

NGINX matches location blocks in order of specificity. The most specific (/api/v2/) must come first, then /api/v1/, then the general /api/.

✅ Best Practice

expert

Best practice for API versioning in NGINX with minimal config duplication

Which NGINX configuration approach best minimizes duplication while supporting multiple API versions with shared common settings?

A Use regex locations for each version with repeated proxy settings

B Create separate location blocks for each version with duplicated proxy settings

C Use <code>if</code> statements inside location to switch proxy_pass URLs

D Use a single location /api/ with <code>map</code> to select backend based on header and common proxy settings inside location

💡 Hint

Think about how to reuse proxy settings and avoid repeating code.

Using map to select backend based on header allows one location block with shared proxy settings, reducing duplication and easing maintenance.