Why Nginx handles API routing - Visual Breakdown

Process Flow - Why Nginx handles API routing

Client sends API request

↓

Nginx receives request

↓

Check request URL path

Yes No↓

Forward to API server

↓

API server processes request

↓

Response sent back through Nginx

↓

Client receives API response

Nginx receives client requests, checks if the URL path matches API routes, forwards API requests to the API server, and returns the response to the client.

Execution Sample

Nginx

location /api/ {
    proxy_pass http://api_backend;
}

This Nginx config routes all requests starting with /api/ to the API backend server.

Process Table

Step	Request URL	Nginx Action	Routing Decision	Result
1	/api/users	Check URL path	Matches /api/	Forward to API backend
2	/api/users	Proxy request	Send to http://api_backend	API server processes
3	/api/users	Receive response	From API backend	Send response to client
4	/index.html	Check URL path	Does not match /api/	Serve static file
5	/index.html	Serve file	Static content	Send file to client

💡 Requests not matching /api/ are served as static files; /api/ requests are proxied to API backend.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
Request URL	N/A	/api/users	/api/users	/api/users	Response sent
Routing Decision	N/A	Matches /api/	Forwarded	Response received	Completed
Response	N/A	N/A	Pending	Received from API	Sent to client

Key Moments - 3 Insights

Why does Nginx check the URL path before forwarding?

Nginx uses the URL path to decide if the request is for the API or for static content. This is shown in execution_table step 1 where the URL is checked to match /api/.

What happens if the URL does not start with /api/?

Nginx serves the request as static content or other configured content, as seen in execution_table step 4 and 5.

How does Nginx forward the API request to the backend?

Nginx uses proxy_pass to send the request to the API backend server, shown in execution_table step 2.

Visual Quiz - 3 Questions

Look at the execution table, what is the routing decision at step 1 for URL /api/users?

A Matches /api/, forward to API backend

B Does not match /api/, serve static file

C Send error response

D Ignore request

💡 Hint

Check the 'Routing Decision' column in row for step 1.

At which step does Nginx send the API response back to the client?

A Step 2

B Step 4

C Step 3

D Step 5

💡 Hint

Look at the 'Result' column for when response is sent to client.

If the request URL is /home, what would Nginx do according to the execution table?

A Forward to API backend

B Serve static file

C Return 404 error

D Proxy to another server

💡 Hint

See steps 4 and 5 for requests not matching /api/.

Concept Snapshot

Nginx routes API requests by matching URL paths.
Use 'location /api/' block to proxy API calls.
Requests matching /api/ go to backend server.
Others serve static files or default content.
This improves performance and organization.

Full Transcript

When a client sends a request, Nginx first checks the URL path. If the path starts with /api/, Nginx forwards the request to the API backend server using proxy_pass. The API server processes the request and sends the response back through Nginx to the client. If the URL does not start with /api/, Nginx serves static files or other content directly. This routing helps separate API traffic from static content efficiently.

Practice

1. Why is Nginx commonly used to handle API routing in web applications?

easy

A. Because it replaces the need for backend servers

B. Because it efficiently directs API requests to the correct backend services

C. Because it stores API data permanently

D. Because it automatically writes API documentation

Solution

1. Step 1: Understand Nginx's role in routing

   Nginx acts as a traffic controller, sending API requests to the right backend service based on rules.

2. Step 2: Identify what Nginx does not do

   Nginx does not store data, replace backend servers, or write documentation; it only routes requests.

3. Final Answer:

   Because it efficiently directs API requests to the correct backend services -> Option B

4. Quick Check:

   Routing = directing requests [OK]

Hint: Nginx routes requests, it doesn't store or create data [OK]

Common Mistakes:

• Thinking Nginx stores API data
• Believing Nginx replaces backend servers
• Assuming Nginx writes API docs

2. Which Nginx directive is used to forward API requests to a backend server?

easy

A. proxy_pass

B. listen

C. server_name

D. root

Solution

1. Step 1: Identify the directive for forwarding requests

   The proxy_pass directive tells Nginx where to send the incoming API requests.

2. Step 2: Differentiate from other directives

   listen sets the port, server_name sets the domain, and root sets the file path, none forward requests.

3. Final Answer:

   proxy_pass -> Option A

4. Quick Check:

   Forwarding = proxy_pass [OK]

Hint: proxy_pass sends requests to backend servers [OK]

Common Mistakes:

• Confusing listen with proxy_pass
• Using root to forward requests
• Mixing server_name with routing

3. Given this Nginx config snippet, what backend URL will a request to /api/users be forwarded to?

location /api/ {
    proxy_pass http://backend-service:8080/;
}

medium

A. http://backend-service:8080/api/users

B. http://backend-service:8080/

C. http://backend-service:8080/api/

D. http://backend-service:8080/users

Solution

1. Step 1: Understand proxy_pass with trailing slash

   Since proxy_pass ends with a slash, Nginx replaces the matching /api/ part in the request URL with the backend URL.

2. Step 2: Apply URL rewrite logic

   Request /api/users becomes /users appended to http://backend-service:8080/, resulting in http://backend-service:8080/users.

3. Final Answer:

   http://backend-service:8080/users -> Option D

4. Quick Check:

   Trailing slash rewrites path [OK]

Hint: Trailing slash in proxy_pass rewrites matched path [OK]

Common Mistakes:

• Appending full original path without rewrite
• Ignoring trailing slash effect
• Assuming no path change

4. Identify the error in this Nginx config that prevents API routing:

location /api {
    proxy_pass http://backend-service:8080;
}

medium

A. Missing trailing slash in location path

B. proxy_pass must use HTTPS instead of HTTP

C. proxy_pass URL missing trailing slash causing path issues

D. location directive should be inside server block

Solution

1. Step 1: Check proxy_pass URL format

   The proxy_pass URL lacks a trailing slash, so Nginx appends the full original request URI, causing incorrect backend paths.

2. Step 2: Understand impact on routing

   Without the trailing slash, requests like /api/users become http://backend-service:8080/api/users which may not be expected by backend.

3. Final Answer:

   proxy_pass URL missing trailing slash causing path issues -> Option C

4. Quick Check:

   Trailing slash in proxy_pass fixes path [OK]

Hint: Always add trailing slash in proxy_pass for correct routing [OK]

Common Mistakes:

• Ignoring trailing slash importance
• Thinking location path needs trailing slash
• Assuming HTTPS is mandatory

5. You want Nginx to route requests starting with /api/v1/ to http://v1-backend:9000/ and requests starting with /api/v2/ to http://v2-backend:9000/. Which configuration correctly achieves this?

hard

A. location /api/v1/ { proxy_pass http://v1-backend:9000/; }\nlocation /api/v2/ { proxy_pass http://v2-backend:9000/; }

B. location /api/ { proxy_pass http://v1-backend:9000/; }\nlocation /api/ { proxy_pass http://v2-backend:9000/; }

C. location /api/v1 { proxy_pass http://v1-backend:9000; }\nlocation /api/v2 { proxy_pass http://v2-backend:9000; }

D. location /api/v1/ { proxy_pass http://v2-backend:9000/; }\nlocation /api/v2/ { proxy_pass http://v1-backend:9000/; }

Solution

1. Step 1: Match location blocks to API versions

   Separate location blocks for /api/v1/ and /api/v2/ ensure requests route to correct backend.

2. Step 2: Use trailing slashes in proxy_pass URLs

   Trailing slashes in proxy_pass ensure correct path rewriting for backend services.

3. Step 3: Verify options

   location /api/v1/ { proxy_pass http://v1-backend:9000/; }\nlocation /api/v2/ { proxy_pass http://v2-backend:9000/; } correctly matches paths and proxies to correct backends. location /api/ { proxy_pass http://v1-backend:9000/; }\nlocation /api/ { proxy_pass http://v2-backend:9000/; } duplicates location blocks, location /api/v1 { proxy_pass http://v1-backend:9000; }\nlocation /api/v2 { proxy_pass http://v2-backend:9000; } misses trailing slashes, location /api/v1/ { proxy_pass http://v2-backend:9000/; }\nlocation /api/v2/ { proxy_pass http://v1-backend:9000/; } swaps backends incorrectly.

4. Final Answer:

   location /api/v1/ { proxy_pass http://v1-backend:9000/; }\nlocation /api/v2/ { proxy_pass http://v2-backend:9000/; } -> Option A

5. Quick Check:

   Separate locations + trailing slash = correct routing [OK]

Hint: Use distinct location blocks with trailing slashes for each API version [OK]

Common Mistakes:

• Using same location for different APIs
• Missing trailing slashes causing path errors
• Swapping backend URLs by mistake