docs(http): add ADR-043 WebTransport bidirectional ALPN substrate; fix spec drift from mid-spec pivot
A consistency review of the alknet-http specs found two classes of
issues: internal contradictions from the mid-spec pivot (the to_openapi
gateway pattern landed in prose but not in cross-references), and a
systematic client→server assumption that only holds for the OpenAPI/MCP
case leaking into the WebTransport architecture.
Class 1 (internal contradictions):
- C1: to_openapi was half-refactored — body described the ADR-042
gateway pattern but the decisions table and ADR-036 still said
'paths mirror /{service}/{op}'. ADR-036's to_openapi clause is now
amended as superseded by ADR-042; the stale decisions row and README
Principle 2 are fixed.
- C2: the axum Router route list didn't include the 5 gateway endpoints
(/search, /schema, /call, /batch, /subscribe). Added them; clarified
/openapi.json as the gateway description doc; added gateway paths to
the decoy exclusion list.
- C3: ADR-034 §5 still talked about the 'h3/WebTransport deferral
bucket' that ADR-038 eliminated. Amended §5/Consequences/References
to drop the deferral framing (the auth-model decision stands; only
the 'when' wording was stale).
Class 2 (one-way direction assumption):
- C4/C5/C6: the WebTransport specs framed the session as browser→hub
one-way, when the call protocol is bidirectional and WebTransport is
a general ALPN transport substrate. New ADR-043 reframes WebTransport
as a bidirectional ALPN transport substrate (call protocol is the
first/canonical target; needs no WASM parser), names the call
protocol's bidirectionality over WebTransport sessions, and states
the inbound no-PeerId connection-local overlay as the mirror of
ADR-034 §2. webtransport.md is updated to reflect this framing;
ADR-040 is repositioned (not superseded) as the substrate's non-call-
ALPN mechanism.
- C7: the HTTP/1.1+HTTP/2 surface's one-directionality is now named as
a lossy consequence of HTTP request/response; WebTransport is named
as the surface that restores the bidirectional call model.
- C8: overview.md acknowledges the from/to direction model is
OpenAPI/MCP-specific, not a call-protocol property.
A review subagent pass on ADR-043 + webtransport.md found no critical
issues; warnings W1-W3 (residual browser-as-subject framing, ADR-009
rationale in spec, opening abstract tone) and suggestions S2/S4/S5
were addressed.
This commit is contained in:
@@ -57,6 +57,21 @@ spec's `paths` mirror the `/{service}/{op}` operation paths. An external
|
||||
client reading the OpenAPI doc learns the same routes the HTTP handler
|
||||
serves; there is no second mapping.
|
||||
|
||||
> **Amendment (superseded by [ADR-042](042-openapi-gateway-pattern.md) on
|
||||
> the `to_openapi` clause):** The paragraph above described the original
|
||||
> "per-operation-paths projection" — `to_openapi` generating one OpenAPI
|
||||
> path entry per `External` operation, mirroring `/{service}/{op}`. ADR-042
|
||||
> replaces this with the **gateway pattern**: `to_openapi` generates 5
|
||||
> fixed gateway endpoints (`/search`, `/schema`, `/call`, `/batch`,
|
||||
> `/subscribe`) instead of one path per operation. The "no second routing
|
||||
> table" property is preserved (the gateway endpoints are fixed; the
|
||||
> per-caller operation surface is discovered via `/search`, not preloaded
|
||||
> into a generated path set). The direct-call surface (`POST
|
||||
> /{service}/{op}`) that this ADR defines is **unchanged** — ADR-042 only
|
||||
> changes what `to_openapi` *describes*, not what the HTTP handler
|
||||
> *serves*. A traditional per-operation-paths OpenAPI projection remains
|
||||
> available as an additive alternative (ADR-042 §5).
|
||||
|
||||
### HTTP method semantics
|
||||
|
||||
The call protocol's `OperationType` (`Query`, `Mutation`, `Subscription`,
|
||||
@@ -191,6 +206,10 @@ without auth before identity is resolvable.
|
||||
`to_openapi` as a projection; published-spec compatibility contract
|
||||
- [ADR-023](023-operation-error-schemas.md) — error schema fidelity in
|
||||
`from_openapi`/`to_openapi`; HTTP status mapping
|
||||
- [ADR-042](042-openapi-gateway-pattern.md) — supersedes this ADR's
|
||||
`to_openapi` clause (the per-operation-paths projection is replaced by
|
||||
the 5-endpoint gateway pattern; the direct-call surface this ADR
|
||||
defines is unchanged)
|
||||
- OQ-13 (resolved) — operation path format `/{service}/{op}`
|
||||
- `docs/research/alknet-http/phase-0-findings.md` DH-3 — the decision this
|
||||
ADR resolves
|
||||
|
||||
Reference in New Issue
Block a user