API gateway patterns in Rest API - Mini Project: Build & Apply

API gateway patterns

📖 Scenario: You are designing an API gateway configuration for an e-commerce platform with three backend services: Users, Products, and Orders. The gateway needs to route requests, aggregate responses for a dashboard endpoint, and apply rate limiting.

🎯 Goal: Design a gateway routing configuration, a response aggregation endpoint, rate limiting rules, and request transformation headers for a multi-service REST API.

📋 What You'll Learn

Define path-based routing rules for three backend services

Design a dashboard aggregation endpoint combining data from all services

Configure rate limiting rules per client tier

Add standard gateway headers for request tracing

💡 Why This Matters

🌍 Real World

API gateways like Kong, AWS API Gateway, and NGINX are used in every microservices architecture to centralize routing, security, and observability.

💼 Career

Backend and DevOps engineers configure API gateways daily to manage service communication, enforce security policies, and optimize client-server interactions.

1

Define path-based routing rules

Create a JSON routing configuration with a routes array. Each route should have a path pattern, method, and upstream target. Route /api/users/* to http://user-service:3001, /api/products/* to http://product-service:3002, and /api/orders/* to http://order-service:3003. Set strip_prefix to "/api".

Rest API

{
  "gateway": {
    "routes": [
      // Add route objects with path, method, upstream, and strip_prefix
      // Your code here
    ]
  }
}

Hint

Each route maps a URL path pattern to a backend service address. The strip_prefix removes /api before forwarding.

2

Design dashboard aggregation endpoint

Add an aggregation section to the gateway config. Define an endpoint /api/dashboard with method GET that calls three upstream endpoints: /users/current from user-service mapped to response key "user", /orders/recent from order-service mapped to "recent_orders", and /products/featured from product-service mapped to "featured_products".

Rest API

{
  "gateway": {
    "routes": [
      { "path": "/api/users/*", "method": "ALL", "upstream": "http://user-service:3001", "strip_prefix": "/api" },
      { "path": "/api/products/*", "method": "ALL", "upstream": "http://product-service:3002", "strip_prefix": "/api" },
      { "path": "/api/orders/*", "method": "ALL", "upstream": "http://order-service:3003", "strip_prefix": "/api" }
    ],
    "aggregation": [
      // Add aggregation endpoint that combines data from all three services
      // Your code here
    ]
  }
}

Hint

The aggregation endpoint makes parallel calls to multiple services and combines their responses into a single JSON object using response keys.

3

Configure rate limiting rules

Add a rate_limiting section with two tiers: "free" with 100 requests per 3600 seconds, and "premium" with 10000 requests per 3600 seconds. Set the identify_by field to "api_key" and exceeded_response to status 429 with message "Rate limit exceeded".

Rest API

// Configure rate limiting with free and premium tiers
// Your code here

Hint

Define tiers with requests-per-window limits and a response to return when limits are exceeded.

4

Add request transformation headers

Add a request_transform section with a headers object. Add three headers: X-Request-ID set to "$uuid" (auto-generated), X-Forwarded-For set to "$client_ip", and X-Gateway-Version set to "1.0". Also add a remove_headers array that removes "X-Powered-By" from upstream responses.

Rest API

// Add headers for tracing and remove internal headers from responses
// Your code here

Hint

Use variable placeholders like $uuid and $client_ip for dynamic values. Remove internal headers to avoid leaking implementation details.

Practice

1. What is the primary role of an API Gateway in a microservices architecture?

easy

A. To act as a single entry point that routes client requests to multiple backend services

B. To store data persistently for backend services

C. To replace all backend services with a monolithic service

D. To serve as a database query optimizer

Solution

1. Step 1: Understand the role of API Gateway

   An API Gateway acts as a single entry point for clients to access multiple backend services, simplifying client communication.

2. Step 2: Eliminate incorrect options

   Options A, C, and D describe roles unrelated to API Gateway functions like data storage or replacing services.

3. Final Answer:

   To act as a single entry point that routes client requests to multiple backend services -> Option A

4. Quick Check:

   API Gateway = Single entry point routing [OK]

Hint: API Gateway = single access point for many services [OK]

Common Mistakes:

• Confusing API Gateway with database or storage
• Thinking API Gateway replaces backend services
• Assuming API Gateway only handles security

2. Which of the following is the correct way to configure an API Gateway to route requests to a backend service named user-service?

easy

A. "/users": "user-service/api/v1/users"

B. "/users": "http://user-service/api/v1/users"

C. "users": "http://user-service/api/v1/users"

D. "/users": "http://user-service/api/v1"

Solution

1. Step 1: Check URL path and protocol

   The route key should start with a slash and the backend URL must include the protocol (http://) and full path.

2. Step 2: Validate each option

   "/users": "http://user-service/api/v1/users" correctly uses "/users" as route and full URL with protocol and path. "/users": "user-service/api/v1/users" misses protocol. "users": "http://user-service/api/v1/users" misses leading slash in route. "/users": "http://user-service/api/v1" misses the full path to users.

3. Final Answer:

   "/users": "http://user-service/api/v1/users" -> Option B

4. Quick Check:

   Route starts with / and URL includes http:// [OK]

Hint: Routes start with / and backend URLs need protocol [OK]

Common Mistakes:

• Omitting http:// in backend URL
• Missing leading slash in route path
• Using incomplete backend service path

3. Given the following API Gateway configuration snippet, what will be the response path for a client request to /orders/123?

{
  "/orders": "http://order-service/api/v2/orders"
}

medium

A. http://order-service/api/v2/orders/orders/123

B. http://order-service/api/v2/orders

C. http://order-service/orders/123

D. http://order-service/api/v2/orders/123

Solution

1. Step 1: Understand path forwarding in API Gateway

   The gateway appends the path after the route key to the backend URL. Here, "/orders" is the route key, so "/123" is appended.

2. Step 2: Construct the full backend URL

   Appending "/123" to "http://order-service/api/v2/orders" results in "http://order-service/api/v2/orders/123".

3. Final Answer:

   http://order-service/api/v2/orders/123 -> Option D

4. Quick Check:

   Request path appended after route key URL [OK]

Hint: API Gateway appends extra path after route key URL [OK]

Common Mistakes:

• Not appending the extra path segment
• Duplicating the route key in backend URL
• Ignoring the original request path

4. An API Gateway is configured with the following routes:

{
  "/products": "http://product-service/api/products",
  "/products/details": "http://product-details-service/api/details"
}

A client request to /products/details/456 returns a 404 error. What is the likely cause?

medium

A. The more specific route "/products/details" is shadowed by the generic "/products" route

B. The backend URL for "/products/details" is missing the protocol

C. API Gateway does not support nested routes

D. The client request path is malformed

Solution

1. Step 1: Analyze route matching order

   API Gateways usually match routes in order or by specificity. If the generic "/products" route is matched first, it will forward requests to product-service, ignoring the more specific route.

2. Step 2: Understand 404 cause

   The product-service likely does not handle "/details/456", causing 404. The specific route is shadowed and never reached.

3. Final Answer:

   The more specific route "/products/details" is shadowed by the generic "/products" route -> Option A

4. Quick Check:

   Route specificity matters to avoid shadowing [OK]

Hint: Specific routes must be checked before generic ones [OK]

Common Mistakes:

• Ignoring route matching priority
• Assuming API Gateway can't handle nested routes
• Blaming client request format without checking routes

5. You need to design an API Gateway pattern that aggregates data from user-service and order-service to provide a single response for a client request to /user-orders/{userId}. Which pattern best fits this requirement?

hard

A. Rate limiting pattern to restrict client requests

B. Simple proxy pattern forwarding requests directly to one service

C. Backend for Frontend (BFF) pattern to combine multiple service responses

D. Circuit breaker pattern to handle service failures

Solution

1. Step 1: Identify the need for data aggregation

   The client wants combined data from two services in one response, which requires aggregation logic.

2. Step 2: Match pattern to requirement

   The Backend for Frontend (BFF) pattern is designed to aggregate and tailor responses for specific client needs by calling multiple backend services.

3. Final Answer:

   Backend for Frontend (BFF) pattern to combine multiple service responses -> Option C

4. Quick Check:

   Data aggregation needs BFF pattern [OK]

Hint: Aggregate multiple services with Backend for Frontend pattern [OK]

Common Mistakes:

• Choosing simple proxy which doesn't aggregate
• Confusing rate limiting with aggregation
• Using circuit breaker which handles failures, not aggregation