Namespace Kuestenlogik.Bowire.Mock.Matchers

Classes

ExactMatcher

Default matcher for the Phase-1 / Phase-2 mock. Handles two protocol families:

• REST — matches recorded steps by (httpVerb, httpPath). The path is either a literal (/weather, exact string match) or an OpenAPI-style template (/users/{id}, each {name} segment binds to one path segment). Verb case-insensitive, literal-path case-sensitive per the HTTP spec.
• gRPC — matches requests carrying an application/grpc-family content type by the /{service}/{method} URL path.

Non-unary steps are always skipped. When several recorded steps share the same verb + path template (e.g. three captures of GET /pet/{petId} with petId = 3, 5, 10), the matcher scores each candidate by how well its recorded request body matches the incoming path-bindings and picks the best hit — so a mock call against /pet/5 returns the response for petId = 5 instead of always handing back the first capture. Ties (and the historical single-template path) keep the original "first match wins" order. Phase 2 later adds a topic matcher for MQTT / Socket.IO wildcards as a separate IMockMatcher implementation.

MockRequest

The bits of an incoming wire request the matcher can reason about. Populated by MockHandler (embedded mode) or by the standalone MockServer listener.

Interfaces

IMockMatcher

Plugs the mock server's request-matching strategy. Implementations look at an incoming MockRequest and decide which recorded BowireRecordingStep (if any) should answer it. Phase 1 ships ExactMatcher; Phase 2 adds path and topic matchers.