Stéphane Tailland
bf5adadb24
6 routes over Payment, composite key (customernumber + checknumber), proxying to classic-models-api. openid-connect with RFC 8693 token exchange to classic-models-api audience, rate-limiting, proxy-cache, audit-log — same structure as customers-api's REST layer. Keycloak (local): payments-api-audience client scope + payments-api resource client added, attached to kong-token-exchange-broker's default scopes. No dedicated protocol mappers on payments-api itself, same practice as customers-api/mcp-customers. No MCP layer — same as customers-api, not needed yet.
2.6 KiB
payments-api
Kong routing/policy layer for the payments slice of
classic-models-api (see /Users/stephanetailland/git/classic-models-api),
split out per the DDD decomposition in ../kong-konnect-deployment-strategy.md.
The backend itself stays a single monolith — only Kong does the domain
split. Structure mirrors ../customers-api, not ../catalog-api — see
../STATUS.md section 18 for why (catalog-api's two-route MCP pattern
has a latent bug; customers-api's single-route pattern is the corrected
one to copy going forward).
REST only, no MCP layer. 6 routes over Payment, which uses a
composite key (customernumber + checknumber, not a single id like
Customer/Product) — both URI segments are captured and passed through
to the backend's own composite-key URL pattern.
| Route | Method | Backend path |
|---|---|---|
/payments/v1/payments/ |
GET, POST | /classic-models/api/v1/payments/ |
/payments/v1/payments/{customernumber}/{checknumber}/ |
GET, PUT, PATCH, DELETE | /classic-models/api/v1/payments/{customernumber}/{checknumber}/ |
Auth
openid-connect, audience_required/token-exchange target =
classic-models-api (BACKEND_AUDIENCE) — same second-hop-exchange
pattern as customers-api's REST layer: a caller gets a
payments-api-audience token from kong-token-exchange-broker directly
(no MCP hop exists for this domain), and this layer exchanges it again to
classic-models-api before the backend ever sees it. IdP is the local
Keycloak (https://keycloak.sttlab.local/realms/classic-models) — see
../STATUS.md sections 15/16. No payments-api Keycloak client or
payments-api-audience client scope exists yet — unlike customers-api,
this hasn't been created on the local Keycloak (nor attached to
kong-token-exchange-broker's default scopes) as of this repo's initial
build. Nothing can actually authenticate against these routes until that's
done — same missing piece as customers-api had before its own Keycloak
wiring step.
Other policies
Per-consumer rate limiting, response caching (GET/HEAD), audit log
(http-log, endpoint still a placeholder — no real log collector in this
lab, same caveat as the other domains).
Structure
Same dev/ + kong/rest/ layout as customers-api. Deploy key
(kong-v2/payments-api/git-deploy-key) is a copy of catalog-api's,
not a freshly generated one — per the user's explicit instruction this
session ("no reason a working key for catalog-api wouldn't work for
customers-api"), the same reused key is used here too rather than minting
yet another one per domain.