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.

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