In WireMock, how does snapshotRecord() differ from a startRecording() session for kayak-rental traffic?

## Two directions on the same artefact WireMock gives you two ways to end up with stub mappings built from real traffic, and confusing them is the most common source of an empty or duplicated capture. They differ in one axis only: **when the decision to record is made relative to the traffic.** - WireMock's `startRecording(...)` is a *prospective* session. You decide first, then generate the traffic. WireMock proxies to the target you named and captures from that instant until `stopRecording()`. - WireMock's `snapshotRecord()` is a *retrospective* conversion. The traffic has already been served; the call turns what the server has kept about it into stub mappings. Nothing needs to have been armed in advance. Both hand back a WireMock `SnapshotRecordResult` and both register the resulting stubs on the running server, so downstream everything looks identical. The difference is entirely about which one you *could have* used. ## What the session form requires of you WireMock's `startRecording("https://kayaks.riverbend.example")` needs a target, because the session is what arranges the forwarding. Its constraints follow from that: - you must call it *before* the kayak-rental client makes the calls you want; - the window is bounded by WireMock's `stopRecording()`, and once that returns the window is gone; - the server is genuinely in a different mode for the duration, which WireMock's `getRecordingStatus()` will report as `Recording`. It is the right shape when a test fixture owns the whole interaction: arm, drive, stop, inspect. ## What the snapshot form requires of you WireMock's `snapshotRecord()` needs no target, because it is not arranging any forwarding — it is reading what the server has already served and converting it. Its constraints are the mirror image: - something must already have produced real exchanges through this WireMock, typically because a proxy arrangement was in place; - the conversion is not a consuming read, so calling it twice converts the same traffic twice and you end up with duplicate mappings; - it converts everything in scope, not just your test's calls, which on a shared server means somebody else's kayak-rental traffic lands in your set. ## Choosing between them | situation | reach for | |---|---| | A fixture that arms, drives and stops in one method | WireMock's `startRecording(...)` / `stopRecording()` | | A client already driven by hand through a browser | WireMock's `snapshotRecord()` | | A proxying server that has been running all morning | WireMock's `snapshotRecord()` | | A window you want explicitly bounded and observable | WireMock's `startRecording(...)` / `stopRecording()` | The practical rule is short: **if you have not decided yet, you still have the snapshot option; if you have decided in advance, the session gives you a cleaner boundary.** ## Shaping either one Both calls take the same specification object. In WireMock, `snapshotRecord(recordSpec()...)` and `startRecording(recordSpec()...)` are the fuller forms, and the spec is where you narrow what the conversion produces — which request headers become part of the recorded match, how large a body must be before it is extracted to a file, whether repeated identical requests are collapsed. On a snapshot this is not a nicety: because a snapshot converts everything in scope, the spec is often the only thing standing between you and a hundred mappings from a polling client. ## The three traps 1. **The double snapshot.** Two WireMock `snapshotRecord()` calls with nothing cleared between them produce the same mappings twice. The set silently doubles and the duplicates match identically, so nothing fails loudly. 2. **The empty snapshot.** If no real exchanges ever occurred — the client was answered by existing stubs, or never reached WireMock — the snapshot has nothing to convert and returns an empty result. The instinct is to blame the call; the cause is upstream of it. 3. **The borrowed traffic.** On a WireMock several suites drive, a snapshot cannot tell whose kayak-rental calls it is converting. It converts all of them. ## What neither one does Neither call cleans anything up. A recorded `rentalId`, a captured `Authorization` header and a frozen `availableFrom` timestamp are equally present whichever route you took, because both are converting the same real exchanges. Nor does either one decide where the mappings ultimately live or how a committed set is later regenerated — that is separate machinery with its own controls. The two calls in this question answer exactly one question between them: *given some real traffic, how do I turn it into WireMock stub mappings, and did I know in advance that I wanted to?* Mountebank has no equivalent of the retrospective form — an imposter either carries a `proxy` response that records as it serves, or it does not.