liveBook · Manning

Declarative configuration

As explained in Automating API Delivery

Declarative configuration specifies a system's desired state while leaving a tool or agent to determine and execute the commands needed to achieve it.

An API gateway needs a deployment configuration before it can expose a backend service to consumers. A declarative configuration states the gateway’s desired operating state—such as routes, authentication, usage plans, rate limits, and logging—without prescribing the commands that create it. section 1.5.5

Write the required property values in a file; a tool or agent reads them and performs the implementation steps. An imperative script instead specifies which commands run and in what order. The declarative approach separates decisions about the required state from the commands needed to achieve it. section 1.5.5 section 9.4.1

For an APIOps deployment:

  • Store each environment’s gateway configuration in Git and make updates there rather than through the gateway UI. Version history supports collaboration and auditing; pull requests and CODEOWNERS can control approvals. section 1.5.5 section 9.4.1
  • Have an automated agent or deployment pipeline obtain the declared state and apply it. Reconciliation compares actual state with desired state and attempts to correct drift. section 9.4.1
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

The Kong YAML provides a concrete configuration: a backend service on port 8080, a GET route constrained by host and path, and key-auth requiring an x-api-key header. section 6.2.2

Check the gateway route

From the Kong configuration directory, run `kong start -c kong.conf`. Request `GET http://localhost:8000/v1/catalog/products/612b4280-b5c0-4ad5-bce7-ede7ab2b80fc` with `Host: api.acme-pet-supplies.com` and `x-api-key: my_secret_api_key`. A product response confirms that the request reached the secured API through the gateway. Without the configured Host header, the request will not match this route; consumers must also supply the configured API key. section 6.2.2

How Automating API Delivery covers it

How deep it goes
Defines desired-state configuration, contrasts it with imperative scripts, and demonstrates gateway routing and authentication without detailing the agent’s commands.
Examples
Uses Kong YAML and a curl request with Host and x-api-key headers to verify a secured product route.
What it assumes
Assumes an implemented backend API service and introduces the declarative-versus-imperative distinction before gateway deployment.
What you can do after
Apply it via Kong to route and secure an API, then verify the gateway request with curl.
How it connects
Connects API gateways, GitOps, configuration as code, API-key authentication, and drift reconciliation.

Also explained in

Compare how 6 books explain declarative configuration →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Automating API Delivery. The section links point to the parts of the book it draws on.