Expand description
HTTP-shaped per-request work and the in-pipeline Context service contract.
Two request types coexist here, intentionally:
-
YetiRequest/YetiResponse— the protocol-edge shape (http::Request<Bytes>/http::Response<Bytes>). Every transport (HTTP, MQTT, MCP) translates its inbound payload into this, runs edge-level Services (e.g.tower-httpCORS / compression / tracing), and translates the response back. Plugins targeting raw HTTP edge concerns implementService<YetiRequest>. -
ContextService— the internal pipeline shape. Once the router has resolved app/resource/path-id and constructed aContext, every downstream layer (auth resolution, rate limiting, table dispatch) is aService<Context, Response = Context, Error = YetiError>.
Context is Clone: every field is Bytes / Arc<str> /
Arc<dyn Trait> / small map, so cloning is cheap. With Clone,
Context flows through tower::Service<YetiRequest> chains via
http::Request::extensions (the standard tower-http pattern).
Structs§
- Request
Pipeline - Sequential runner for a chain of
ContextServices. The pipeline owns the services and threads aContextthrough them one after another, short-circuiting on the first error.
Functions§
- compose
- Compose a slice of
ContextServices into a singleContextServicethat runs them in registration order. The composed service isBoxCloneSyncService, so cloning it is oneArcbump regardless of chain length. Each underlying service still requires a per-callclone(to satisfy&mut self), but the outer container is shared — so the per-request work scales with chain length only inside theFuture, not at the boundary.
Type Aliases§
- Context
Service - The middleware-pipeline service type. Each registered service consumes
a
Contextand returns a (possibly mutated)Context, or fails withYetiError. - Yeti
Request - The canonical Yeti request —
http::Request<Bytes>— for protocol-edge services. The router peels this apart into aContextbefore invoking the middleware pipeline. - Yeti
Response - The canonical Yeti response —
http::Response<Bytes>.