Expand description
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 singlewhen { … } respond { … }entry.Respond— the declarative description of a response (file / text / status). Does not build thehyper::Response— that’sapimock-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
Respondis interpreted byapimock-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.
Re-exports§
pub use error::RoutingError;pub use error::RoutingResult;pub use parsed_request::ParsedRequest;pub use rule_set::RuleSet;pub use rule_set::rule::Rule;pub use rule_set::rule::respond::Respond;pub use strategy::Strategy;pub use view::MatchConsidered;pub use view::MatchedRule;pub use view::RespondView;pub use view::RouteCatalogSnapshot;pub use view::RouteMatchView;pub use view::RouteValidation;pub use view::RouteValidationIssue;pub use view::RuleSetView;pub use view::RuleView;pub use view::ValidationSeverity;