An API product needs more than a backend service: consumers need an external endpoint that reaches it under the right controls. API configuration tells an API gateway how to route requests to internal services and which interface constraints apply, including security mechanisms and rate limits. An API definition describes the consumer-facing contract; gateway configuration determines how that product is exposed in an environment. section 1.4
Keep gateway configuration declarative and versioned in an environment Git repository. Declare the desired state for each environment—such as backend routing, client authentication, usage plans, rate limits, logging, and monitoring—rather than changing the gateway through its UI. A deployment agent reads that state and applies the necessary changes; engineers propose updates through Git pull requests. section 1.5.5 section 1.5.6
A deployment pipeline can turn that desired state into a tested API product:
- Deploy the backend API service before configuring its gateway route. section 9.4.5
- Validate and reconcile the gateway configuration against the running gateway. A pipeline can push the change, or an operator can watch the environment repository and apply changes it detects. section 9.4.5
- Run API conformance tests after reconciliation to check the exposed route and implementation. Mark the API definition as passing only when those tests succeed. section 9.4.5
Expose a product endpoint through Kong
For a product service reachable as `product-api:8080`, a Kong configuration declares a service and a route accepting `GET` requests on `/v1/catalog/products/...`. In the pipeline, `deck validate --state chapter9/kong.yml` checks the configuration, then `deck sync --state chapter9/kong.yml --kong-addr http://localhost:8001` reconciles it with the running gateway. Conformance tests follow the sync. Kusk takes a different approach: an `x-kusk` extension in the OpenAPI definition names the upstream Kubernetes service, and `kusk deploy` applies the definition from an API registry. section 9.4.5
Listing 9.16 Routing configuration for the Product Catalog API
_format_version: "2.1"
_transform: true
services:
- name: Product_Catalog_API
protocol: http #1
host: product-api #1
port: 8080 #1
path: / #1
routes:
- name: viewProduct
methods: #2
- GET #2
paths: #2
- "~/v1/catalog/products/(.+)$" #2
strip_path: false #2
The Kong routing file shows the two sides of this configuration: an internal service address and an externally matched method and path. section 9.4.5
Reconciliation also addresses configuration drift. If the deployed gateway differs from the desired state in Git, an agent can detect the difference and restore that state. This makes changes auditable and supports rollback with `git revert`; it does not replace review of the API’s resource model or operation design. section 1.5.6 section 1.7
