Features
Request matching and routing
Matching is deterministic and happens before response rendering. It uses method, normalized path, path type, query mode, and route priority.
Purpose
Predict exactly which endpoint rule will run for an incoming request.
Where this is used
- MOCK endpoint selection.
- Passthrough and DISABLED route decisions.
- fallback handling for unmatched paths.
Setup and prerequisites
- At least one endpoint rule with method, path, and query settings.
- Known backend URL if fallback/pass-through is enabled.
- Server is selected and, when needed, running.
Matching checklist
- Method must match exactly.
- Path is normalized (`/users` equals `/users/`).
- Path type check order uses: EXACT → PARAM → WILDCARD → REGEX.
- Query mode filter must pass (`NONE`, `EXACT`, `CONTAINS`).
- If multiple candidates exist, priority rules select one winner.
Expected output
- One matching endpoint is selected if available.
- If none, server fallback applies: STRICT → 404 Not Mocked, FALLBACK → upstream.
- Live View shows final served-by for each request.
Common issues + fixes
- 404 despite route: check method or query mode mismatch.
- Regex path fails: verify regex is valid for regex mode.
- Wildcard not applied: wildcard must be final segment (for example
/api/*). - Unexpected active case: same-route variants auto-disable siblings when one becomes active.
Use matching diagnostics withLive Viewand filter by method/path.
Matching and priority
Screenshot placeholder
Placeholder: route matching inspector with endpoint candidates and selected route details.
