toolkit/api/rest/extract/mod.rs
1//! Canonical-error-aware replacements for axum's built-in extractors.
2//!
3//! Each member of this module delegates to its axum built-in counterpart and
4//! maps the built-in `Rejection` to `CanonicalError`, so a failed extraction
5//! renders as `application/problem+json` instead of axum's default
6//! plain-text rejection body. See `canonical_error_layer.rs`'s doc comment
7//! and `docs/arch/errors/ADR/0006-cpt-cf-adr-error-middleware-catchall.md`
8//! for why this exists.
9//!
10//! **These extractors always fail as JSON.** `CanonicalError`'s
11//! `IntoResponse` impl (`toolkit-canonical-errors`) unconditionally renders
12//! `application/problem+json` - there is no `Accept`-header negotiation, on
13//! a failed extraction here or anywhere else `CanonicalError` is used in
14//! this codebase today. That's the right default for a REST/JSON API gear
15//! (every gear in this workspace, currently). A gear that serves HTML
16//! directly (server-rendered pages, not a JSON API) would still get a JSON
17//! error body from these extractors on a failed `Json`/`Query`/`Path`
18//! extraction, regardless of what its successful response would have been -
19//! for that kind of route, don't adopt these; write a route-specific
20//! extractor (or handle the built-in axum rejection directly) that renders
21//! an HTML error instead.
22
23mod error;
24mod json;
25mod path;
26mod query;
27
28pub use json::Json;
29pub use path::Path;
30pub use query::Query;