CSE 341: Web Services

W07 Learning Activity: API Gateways and Managers

Overview

An ecommerce API may begin as one Express application used by one online store. Later, a mobile app, warehouse system, customer service tool, and business partners may all use it. The team then has more to manage than route handlers and MongoDB queries. It must route traffic, verify identity, limit abusive requests, collect useful logs, and support multiple API versions.

An API gateway can provide one public entrance for those requests. An API management platform can add broader tools for publishing, monitoring, and controlling APIs. You will not deploy these in this course, but understanding them will help you recognize the same concerns in Express middleware and production systems and it will prepare you for your career where your company may use these tools.

The Request Flow

Sequence diagram showing a storefront, mobile app, or partner sending an API request to an API gateway, which applies policies and forwards the request to an Express ecommerce API. The Express API reads or writes MongoDB data, and the response returns through the gateway to the client.
Request flow from an ecommerce client through an API gateway to the Express API and MongoDB. Select the diagram to view a larger version.

The client sends a request to the gateway's public address. The gateway applies general policies and forwards an accepted request to the correct application. The Express API then applies ecommerce rules, reads or writes data, and creates the response.

A gateway is a type of reverse proxy because it receives a request for a backend server and forwards it. A gateway usually adds API-specific policies, such as token checks, rate limits, version routing, and analytics.

Gateway Compared with API Management

A product may provide both. The important difference is the job being discussed: processing a live request is gateway behavior; helping teams publish, discover, analyze, and govern APIs is API management.

Common Gateway Responsibilities

Routing

A gateway can send each public URL to the correct backend. The clients only need to know one public host.

/api/v1/products  -> catalog application
/api/v1/orders    -> order application
/api/v1/users     -> account application

A course project may route all three paths to one Express application. A larger company could deploy them separately without requiring every client to learn the internal addresses.

Authentication

A gateway can verify that an access token has a valid signature and has not expired. Invalid requests can be rejected before they use application or database resources.

Authentication answers, “Who is making this request?” It does not answer every authorization question. The Express application should still decide whether that customer may view a particular order or whether an employee may change a product's price. The application understands those resources and business rules.

Rate Limiting

A rate limit controls how many requests a client may make during a period of time. When the limit is exceeded, an API commonly returns 429 Too Many Requests. Limits protect database connections and application capacity from accidental loops, abusive clients, and sudden large increases in traffic.

Different routes may need different limits. Public product browsing can allow frequent reads. Login attempts should be limited more strongly. Creating an order also deserves care because every successful request writes data and may begin payment or order-processing work, such as preparing an item for shipping.

CORS, Transport, and Security Policies

A gateway can terminate HTTPS, apply security headers, and control which browser origins may call the API. Central policies are useful when several backend applications need the same protection. The application must still be secure when a request reaches it.

Basic Request Validation

A gateway may reject a body that is too large or does not match a basic schema. This avoids sending clearly invalid traffic deeper into the system. The Express application should still validate data quality and business rules.

For example, a gateway can check that quantity is an integer. The application must decide whether the requested product exists, whether enough inventory is available, and whether the customer is allowed to place the order.

Logging, Metrics, and Request IDs

Because requests pass through the gateway, it can record request counts, response times, status codes, active clients, and API version usage. A unique request ID lets a developer connect the gateway log with the Express log for the same request.

Logs should not contain passwords, access tokens, payment card information, or unnecessary personal data. More logging is not always better logging.

Caching

A gateway may briefly cache a public product list. Repeated clients can receive the saved response without running the Express handler and MongoDB query every time. This can improve speed and reduce work.

Caching must match the data. A public product response may be safe to cache for a short time. A customer's cart, address, or order history should not be placed in a shared cache. A bad cache key could even send one customer's private response to another customer.

Version Routing

/api/v1/*  -> version 1 deployment
/api/v2/*  -> version 2 deployment

In a small application, both versions may be Express routers in one deployment. In a larger system, a gateway can send them to separate deployments. Clients keep using one public host either way.

Timeouts and Retries

A gateway can stop waiting when a backend takes too long. It may retry some failed requests, but retries require caution. Repeating a safe GET is different from repeating a POST /orders. If the first POST succeeded but its response was lost, an automatic retry could create a duplicate order. Write operations may need a unique request key that helps the server recognize a repeated request, or another form of duplicate protection.

What Should Stay in Express?

Gateway policies should usually handle concerns that apply across many endpoints. The application should own rules that require knowledge of ecommerce data and behavior.

Do not hide business behavior in infrastructure

A gateway can verify a token, but it should not become the only place that decides whether an order may be canceled. Core rules should remain close to the application code where developers can find, review, and test them.

Gateway-Like Middleware in Express

Express is a series of middleware and route-handler calls. Middleware can inspect a request, change the request or response, end the request, or call next() to continue. This makes it useful for practicing several gateway-like concerns.

The following middleware creates a request ID:

import { randomUUID } from 'node:crypto';

app.use((req, res, next) => {
  req.requestId = randomUUID();
  res.setHeader('X-Request-Id', req.requestId);
  next();
});

A logging middleware can use that ID when the response finishes:

app.use((req, res, next) => {
  const startedAt = Date.now();

  res.on('finish', () => {
    const duration = Date.now() - startedAt;
    console.log({
      requestId: req.requestId,
      method: req.method,
      path: req.originalUrl,
      status: res.statusCode,
      duration
    });
  });

  next();
});

Rate limiting is normally implemented with a tested library or a gateway policy instead of a hand-written counter. One Express example uses express-rate-limit:

import { rateLimit } from 'express-rate-limit';

const apiLimiter = rateLimit({
  windowMs: 60 * 1000,
  limit: 100,
  standardHeaders: 'draft-8',
  legacyHeaders: false
});

app.use('/api', apiLimiter);

These examples help you understand the concerns, but Express middleware is not automatically a full gateway. It runs inside the application, while an external gateway can reject or route requests before they reach the application.

API Management Features

An API management platform may provide additional tools for API producers and consumers:

Risks and Tradeoffs

A gateway adds useful control, but it also adds another system to configure and debug.

Follow Two Ecommerce Requests

For GET /api/v1/products, the gateway may apply a public rate limit, add a request ID, check for a cached response, and route the request. Express searches products and produces the documented JSON. A short public cache may be reasonable.

For POST /api/v1/orders, the gateway verifies the token, applies a stricter rate limit, adds a request ID, and forwards the customer identity. Express checks authorization, validates products and quantities, verifies inventory, calculates the total, and writes the order. This response should not be placed in a shared cache.

This comparison shows the main design rule: the gateway handles broad traffic policies, while Express handles the meaning of the ecommerce operation.

Testing a System That Uses a Gateway

Keep fast automated tests against the Express application. These tests verify product and order behavior even when the gateway is not running. Also run a smaller group of tests in an environment that includes the real gateway configuration.

Gateway-focused tests can verify that invalid tokens are rejected, limits return 429, request IDs are forwarded, versions reach the right backend, and private responses are not cached. Testing both layers makes it easier to tell whether a failure comes from application code or infrastructure configuration.

Activity Instructions

Check your understanding

Answer each question before expanding the example answer.

  1. What is the main difference between an API gateway and API management?

    Click to expand the example answer

    A gateway processes live requests by routing them and enforcing policies. API management covers broader lifecycle work, such as portals, client access, analytics, documentation, and version retirement. A management platform may include a gateway.

  2. If the gateway verifies a customer's token, why must Express still check whether the customer may read a specific order?

    Click to expand the example answer

    The token check proves identity, but it does not prove ownership of that order. Express understands the order data and must enforce resource-specific authorization.

  3. Why might a public product list be cached while a customer's order history is not?

    Click to expand the example answer

    The product list can be the same for many clients and may tolerate a short delay before changes appear. Order history is private and customer-specific. Shared caching could expose it to the wrong person.

  4. Where should the rule “an order cannot contain more items than are in inventory” live?

    Click to expand the example answer

    It should live in the Express application's business logic. The rule requires current product and inventory data and is part of the meaning of placing an order.

  5. What does a 429 Too Many Requests response communicate?

    Click to expand the example answer

    The client exceeded a configured request limit. It should slow down and follow any retry guidance supplied by the API.

  6. Why can automatically retrying POST /orders be dangerous?

    Click to expand the example answer

    The first request may have created an order even if its response was lost. A retry can create a second order unless the system recognizes that it has already processed the same request.

  7. Why should you keep Express tests if production traffic passes through a gateway?

    Click to expand the example answer

    Express tests quickly verify application behavior in isolation. A smaller set of gateway tests verifies the integration and policies. Together they make failures easier to locate.

Submission

When you have completed the learning activities for this week, return to Canvas and complete the associated quiz or checkpoint there.

Other Links: