apimock_routing/lib.rs
1//! Routing model for apimock.
2//!
3//! # Responsibilities
4//!
5//! This crate owns everything declarative about *how* requests match rules:
6//!
7//! - [`RuleSet`] — an ordered collection of rules, plus optional prefix /
8//! default / guard metadata. Loaded from one TOML file.
9//! - [`Rule`] — a single `when { … } respond { … }` entry.
10//! - [`Respond`] — the declarative description of a response (file /
11//! text / status). **Does not** build the `hyper::Response` — that's
12//! `apimock-server`'s job.
13//! - [`Strategy`] — how multiple matching rules in a set are resolved.
14//! (First-match only, at present.)
15//! - Matching primitives: glob, JSONPath, URL-path normalization.
16//! - Read-only views for GUI tooling: [`RouteCatalogSnapshot`],
17//! [`RuleSetView`], [`RuleView`], [`RespondView`], [`RouteMatchView`],
18//! [`RouteValidation`].
19//!
20//! # What is deliberately *not* here
21//!
22//! - HTTP response construction — a matched [`Respond`] is interpreted
23//! by `apimock-server`.
24//! - File I/O for response bodies — also server-side.
25//! - TOML parsing orchestration (which files to load, in which order) —
26//! that's `apimock-config`. This crate only parses an *individual*
27//! rule-set TOML file when asked.
28//!
29//! # Stability
30//!
31//! The types in [`view`] are the stable surface a GUI can depend on.
32//! The internal [`RuleSet`] struct and its methods can still churn as
33//! apimock's rule language evolves — views act as the insulation layer.
34
35pub mod error;
36pub mod parsed_request;
37pub mod rule_set;
38pub mod strategy;
39pub mod util;
40pub mod view;
41
42pub use error::{RoutingError, RoutingResult};
43pub use parsed_request::ParsedRequest;
44pub use rule_set::{RuleSet, rule::Rule, rule::respond::Respond};
45pub use strategy::Strategy;
46pub use view::{
47 MatchConsidered, MatchedRule, RespondView, RouteCatalogSnapshot, RouteMatchView,
48 RouteValidation, RouteValidationIssue, RuleSetView, RuleView, ValidationSeverity,
49};