API gateway patterns in Rest API - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define the main function of an API Gateway that routes requests.

Rest API

def api_gateway(request):
    if request.path == '/users':
        return [1](request)
    else:
        return '404 Not Found'

Drag options to blanks, or click blank then click option'

Aauthenticate_user

Bhandle_users_service

Cprocess_payment_service

Dlog_request

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing a service unrelated to the '/users' path.

Using a function that only logs or authenticates instead of routing.

The API Gateway routes requests to the correct backend service. For '/users' path, it should call handle_users_service.

2fill in blank

medium

Complete the code to add authentication middleware in the API Gateway.

Rest API

def api_gateway(request):
    if not [1](request):
        return '401 Unauthorized'
    # Continue routing

Drag options to blanks, or click blank then click option'

Avalidate_token

Blog_request

Chandle_users_service

Dcache_response

Attempts:

3 left

💡 Hint

Common Mistakes

Using logging or caching functions instead of authentication.

Skipping authentication checks.

The API Gateway should validate the authentication token before routing requests. The function validate_token checks this.

3fill in blank

hard

Fix the error in the code that implements rate limiting in the API Gateway.

Rest API

def api_gateway(request):
    if not [1](request.user_id):
        return '429 Too Many Requests'
    # Continue processing

Drag options to blanks, or click blank then click option'

Acheck_rate_limit

Blog_request

Cvalidate_token

Dhandle_users_service

Attempts:

3 left

💡 Hint

Common Mistakes

Using authentication or logging functions instead of rate limiting.

Not passing the correct user identifier.

The function check_rate_limit should be called to verify if the user has exceeded allowed requests.

4fill in blank

hard

Fill both blanks to implement caching and logging in the API Gateway.

Rest API

def api_gateway(request):
    response = [1](request)
    [2](request, response)
    return response

Drag options to blanks, or click blank then click option'

Aget_cached_response

Blog_request_response

Cvalidate_token

Dhandle_users_service

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing up caching and authentication functions.

Not logging after getting the response.

The API Gateway first tries to get a cached response with get_cached_response. Then it logs the request and response with log_request_response.

5fill in blank

hard

Fill all three blanks to implement request validation, routing, and error handling in the API Gateway.

Rest API

def api_gateway(request):
    if not [1](request):
        return '400 Bad Request'
    try:
        response = [2](request)
    except Exception:
        response = [3]()
    return response

Drag options to blanks, or click blank then click option'

Avalidate_request_schema

Broute_to_service

Chandle_error_response

Dlog_request

Attempts:

3 left

💡 Hint

Common Mistakes

Skipping request validation.

Not catching exceptions properly.

Using logging instead of error handling for exceptions.

The API Gateway first validates the request schema with validate_request_schema. Then it routes the request with route_to_service. If an error occurs, it returns a handled error response with handle_error_response.

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