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.

Routing model for apimock.