When independently deployed microservices must serve one public API product, an API gateway provides the entry point. It is a reverse proxy: consumers call the external interface, and the gateway routes requests to backend services. The gateway can also handle authentication, rate limiting, monitoring, and other concerns shared across services. This separates the client-facing interface from the backend implementation. section 1.4 section 6.2.2
A deployment needs to keep three descriptions aligned:
- The API definition describes the operations and resources offered to consumers. section 1.4
- Gateway configuration maps external requests to internal services and sets policies such as security and rate limiting. section 1.4
- API reference documentation must describe externally observed behavior, including responses generated by the gateway rather than the service. section 6.2.2
Route a catalog request through Kong
A declarative Kong configuration sends GET requests with Host: api.acme-pet-supplies.com and a matching /v1/catalog/products/ path from the gateway on port 8000 to a catalog service on port 8080. Its key-auth plugin reads x-api-key; the example consumer has a configured credential. Test through the gateway with the Host and x-api-key headers, rather than calling port 8080 directly: only the gateway request exercises the configured route and authentication layer. section 6.2.2
Listing 6.4 Kong API gateway declarative configuration
_format_version: "1.1"
services:
- name: Product_Catalog_API
protocol: http
host: localhost
port: 8080
path: /
routes:
- tags:
- Product Catalog
name: viewProduct
methods:
- GET #1
hosts: #1
- api.acme-pet-supplies.com #1
paths: #1
- /v1/catalog/products/(.+)$ #1
strip_path: false #1
plugins: #1
- name: key-auth #2
config:
key_names:
- x-api-key
consumers:
- username: my_api_consumer
keyauth_credentials:
- key: my_secret_api_key
Inspect the service host and port, route method, host and path, then the key-auth plugin and consumer credential. Together they define how an external request reaches the backend and which authentication setting applies. section 6.2.2
An accurate OpenAPI definition can support another gateway check. Gateways with OpenAPI validation can reject requests that fail the schema with HTTP 400 before they reach a backend. Response validation can catch unexpected data; the Kong plugin returns HTTP 406 when that check fails. Similar validation can sit between a platform and a third-party API, provided a suitable definition is available. Operationally, teams can propose gateway-configuration changes for review through an API CI/CD workflow; continuously reconciled configuration can be reverted to a previously working version after a failure. section 10.2.12 section 1.7
