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