Why API gateway patterns in Rest API? - Purpose & Use Cases

The Big Idea

Discover how one smart gateway can turn a messy web of services into a smooth, simple experience!

The Scenario

Imagine you have many different services in your app, each with its own address and rules. To use them, you must call each service separately, remembering their details and handling their differences yourself.

The Problem

This manual way is slow and confusing. You spend too much time writing code to connect to each service, handle errors, and keep track of changes. It's easy to make mistakes and hard to update when services change.

The Solution

API gateway patterns put a single, smart door in front of all your services. This gateway handles requests, routes them correctly, and hides the complexity. You only talk to one place, making your app simpler and faster to build and maintain.

Before vs After

✗ Before

fetch('http://service1/api/data');
fetch('http://service2/api/info');

✓ After

fetch('http://api-gateway/api/data');

What It Enables

With API gateways, you can easily manage many services behind one simple interface, improving security, scalability, and developer experience.

Real Life Example

Think of a shopping app that uses separate services for products, payments, and user profiles. An API gateway lets the app get all needed info through one call, making the app faster and easier to update.

Key Takeaways

Manual calls to many services are complex and error-prone.

API gateways provide a single entry point to simplify communication.

This pattern improves app speed, security, and maintenance.

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