Namespace Kuestenlogik.Bowire.Mocking

Classes

A request-body match predicate (mock matcher, #403). Exactly one mode applies, in this precedence:

JsonPath set → navigate into the JSON body and apply the text op (EqualTo / Contains / Matches) to the value there, or — with no op — assert the path is present (or, with present:false, absent).
EqualToJson set → semantic JSON equality against the whole body (order- and whitespace-insensitive), honouring IgnoreExtraElements and IgnoreArrayOrder.
otherwise → the text op applies to the raw body string.

XPath and JSON-schema body matching are not yet implemented (tracked as a follow-up on #403).

Maps HAR 1.2 documents to BowireRecording instances.

HAR is a well-specified browser-trace format produced by Chrome / Firefox DevTools, Charles, Fiddler, Postman, and Playwright (browser.newContext({ recordHar })). Every entries[] element pairs one HTTP request with its response — exactly what a Bowire REST recording step holds. The mapping is one-to-one for unary REST traffic; streaming / WebSocket / gRPC frames inside a HAR are out of scope (HAR has no native shape for them and the Bowire native recorder covers those protocols directly).

Symmetric to exportRecordingAsHar in the workbench: a recording exported as HAR and re-imported via this class round-trips the unary REST steps. Lossy fields (cache, timings, page IDs, server IPs) are intentionally dropped — the recording format only carries what the mock replayer needs.

Lives in Kuestenlogik.Bowire (core) so both the CLI (bowire import har) and the MCP tool (bowire.har.import) can call it without depending on the CLI host project. The Tool's HarImporter wraps this with file-IO + exit-code shape for the CLI.

BowireHarImportException: Thrown by Convert(string, string?, bool) when the HAR document is malformed.

BowireMatchPredicate: One name-scoped match predicate applied to a query parameter, header, or cookie (mock matcher, #402). The name must be present unless Present is false; when an operator (EqualTo / Matches / Contains) is set, at least one value must satisfy it. With only Name set the predicate asserts mere presence.

BowireRecording: One named recording — an ordered sequence of captured invocations produced by the Bowire UI's recorder and later replayed by the mock server.

BowireRecordingFrame: One frame inside a streaming or duplex recording step — carries the frame payload plus the timestamp offset from the stream start, so streaming replay can pace emission at the original cadence.

BowireRecordingSchemaAnnotation: One effective annotation snapshot inside a BowireRecordingSchemaSnapshot. Matches the four-dimensional addressing the frame-semantics framework uses, plus the resolved Semantic string the workbench uses to pick a widget.

BowireRecordingSchemaSnapshot: Sidecar carried at the top of a Phase-5+ recording file — the set of effective annotations the workbench had resolved for the recorded service+method pairs at record-time. The mock and the recording-replay path use it to mount the same widgets the original session showed, independent of the local annotation store's current state.

BowireRecordingStep: One captured invocation inside a BowireRecording. Mirrors the payload emitted by captureRecordingStep() in the Bowire UI's recording.js.

BowireRecordingStore: On-disk shape of ~/.bowire/recordings.json — a container for one or more BowireRecording instances. The mock server accepts both this wrapper ("full store" file) and a single BowireRecording at the top level (single-scenario file).

BowireStepMatch: Extra REST match predicates + precedence for a recording step (mock matcher, #402). All arms are optional; the matcher applies only the ones set. A path pattern here (PathRegex / PathGlob) overrides the step's httpPath template for path matching; the query / header / cookie predicate lists all have to pass; Priority orders steps that all match.

BowireStepScenario: Named-scenario state-machine gating for a stub (mock matcher, #408) — the analog of WireMock Scenarios. A scenario is a named state; a stub gated on RequiredState only matches while the scenario is in that state, and a match moves the scenario to NewState. Lets the same request return different responses across a lifecycle (e.g. not-found → created → found).

MissingPluginDetector: Diff a recording's protocol IDs against the protocols actually registered in BowireProtocolRegistry. Anything the recording references but the host doesn't know about is returned as a MissingPlugin with a suggested NuGet install line.

MockEmitterOptions: The subset of mock-server configuration that IBowireMockEmitter implementations actually consume. Kept deliberately small so plugin authors don't have to take a compile-time dependency on the full MockOptions shape — which carries server-only concerns (matchers, chaos injection, stateful-cursor bookkeeping) that don't apply to emitters.

MockTransportContext: Run-time context handed to every IBowireMockTransportHost at startup — host bind address, requested port, and the playback knobs (replay speed, loop) that affect proactive emission inside the transport. Per-transport-id; the mock server constructs a separate instance for each registered host.

RecordedInterpretation: One captured interpretation inside a BowireRecordingStep — the addressing path the parent-grouping uses, the resolved Kind (the SemanticTag value), and the type-specific payload inlined as a free-form JsonElement so the replay viewer doesn't have to re-resolve from the raw frame.

RecordingInterpretationBuilder: Phase-5 helper that resolves the effective frame-semantics annotations for a single (service, method) pair against a captured frame and produces the list of RecordedInterpretation entries that land on the recording step. Lives in the Kuestenlogik.Bowire.Mocking namespace because the recording-file shape is owned here, but the logic is disk-I/O-free — pure transformation against an in-memory IAnnotationStore.

RecordingProtocolScanner: Pulls the distinct protocol IDs out of a loaded BowireRecording. Used by bowire mock to detect missing protocol plugins before the server boots — every step references one protocol, and replay needs the matching IBowireProtocol implementation registered in the host.

RecordingReplayInterpretationResolver: Phase-5 replay-determinism shim. Given a recording step (either the top-level BowireRecordingStep or one of its BowireRecordingFrame children) plus the frame about to be emitted, decide whether to short-circuit detection with the captured RecordedInterpretation list or fall back to the live IFrameProber + builder pass.

RecordingSchemaSnapshotBuilder: Phase-5 helper that captures the effective annotation set into a BowireRecordingSchemaSnapshot sidecar at the top of a recording file. The sidecar is what the workbench uses to mount widgets when a recording is opened — so a recording made against one user's annotations renders identically for another user whose local annotations differ.

RecordingSourceSchema: The source-schema document a recording was captured from — carried on SourceSchema when the live target advertised one. Lets the mock server serve the original contract back (REST: GET /openapi.json, AsyncAPI: GET /asyncapi.yaml) so peer discovery against the mock returns the full declared surface rather than the slice the recording happens to cover.

SourceSchemaCache: Process-wide cache of source-schema documents the wire plugins captured at discovery time, keyed by the server URL the discovery ran against. Lets the recording-save endpoint stamp SourceSchema automatically when the workbench writes a new recording, without the JS recorder having to know which plugin owns which URL.

Interfaces

IBowireMockEmitter: Extension point for protocol plugins that need to contribute broadcast-style replay behaviour to the mock server — protocols whose wire model is "server pushes on its own schedule" rather than "client makes a request". MQTT and DIS are the reference implementations (the MQTT emitter is built into the mock server; DIS lives in its own plugin).

IBowireMockHostingExtension: Plugin-contributed hosting extension for the Bowire mock server. Lets a protocol plugin participate in the Kestrel pipeline setup (force HTTP/2, register DI services, map endpoints) based on the loaded recording — without baking protocol-specific knowledge into Kuestenlogik.Bowire.Mock.

IBowireMockLiveSchemaHandler: Optional companion to IBowireMockSchemaSource for schema kinds whose responses can't be pre-baked into a recording (GraphQL is the canonical case — every selection set yields a different response shape, so the mock has to interpret each request as it arrives).

IBowireMockSchemaSource: Plugin-contributed schema-to-recording converter for the Bowire mock server's --schema / --grpc-schema / --graphql-schema family of CLI flags. Each plugin handles one schema kind (OpenAPI on Protocol.Rest, protobuf FileDescriptorSet on Protocol.Grpc, GraphQL SDL on Protocol.GraphQL) and returns a synthesised BowireRecording the standard replay pipeline can serve from.

IBowireMockTransportHost: Plugin-contributed transport host that the Bowire mock server starts alongside its main HTTP listener — for protocols that need their own listener on a separate port (MQTT-broker today, AMQP / DDS / NNG / raw-socket later). Plugins implement this in their own assembly so the heavy transport library (e.g. MQTTnet) hangs only on the protocol-plugin package, not on Kuestenlogik.Bowire.Mock.

Sections

On this page

Namespace Kuestenlogik.Bowire.Mocking

Classes

Interfaces