[Proposal][Design] Per-Operation Upstream Override on OperationRequest #1717
mehara-rothila
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Background
The current
OperationRequestschema cannot direct individual operations to different backend services: every operation in a REST API shares one API-level upstream. This proposal adds per-operation upstream routing so a single API can front multiple microservices without fragmenting the API contract.Proposed Solution
A new optional
upstreamfield onOperationRequest, anOperationUpstreamwrapper withmainandsandboxsub-fields. Each sub-field is anOperationUpstreamTargetthat is ref-only: it names an entry in an API-levelupstreamDefinitionspool. Inline URLs are not used at the operation level; every backend URL is declared once inupstreamDefinitionsand referenced by name. Omitted sub-fields fall back to the API-level upstream for that environment.upstreamDefinitions (the backend pool)
A new API-level array of named backends. Each entry has a
name, an optionalbasePath, an optional connecttimeout, and one or more weightedupstreams(each a backendurl). Both API-level and operation-level refs resolve against this pool, so a backend URL is defined in exactly one place and reused by name.Example
Key Design Features
main/sandboxname anupstreamDefinitionsentry.main/sandboxfalls back to the API-level upstream of the same environment.authat the operation level.^[a-zA-Z0-9\-_]+$(max 100); upstream urls are host-only http/https; connect timeout must be positive; an emptyupstreamwrapper and an emptymain/sandboxleaf are rejected; invalid configs return HTTP 400.Implementation Scope
Platform API: new OpenAPI schemas for the
upstreamDefinitionspool and the ref-onlyOperationUpstream/OperationUpstreamTarget; ref resolution and validation; JSON persistence (no database migration required); emits the deployment artifact the gateway consumes.Gateway Controller: resolves the per-operation ref and points the operation route at the referenced definition's cluster (one cluster per definition, reused by every operation that shares the ref); API-level clusters use identity-based naming so a URL edit is an endpoint update; validation and xDS translation.
Policy Engine (gateway runtime): resolves the per-operation base path so it is applied exactly once, and honors dynamic-endpoint precedence over the static per-operation ref.
Backward Compatibility
The feature maintains full backward compatibility. The
upstreamfield is optional, and existing APIs remain unaffected.Beta Was this translation helpful? Give feedback.
All reactions