How would you standardise what a WireMock recording of the kayak-rental API is allowed to capture?

## Why capture shape is a real decision A WireMock recording is faithful and indiscriminate. It keeps what the kayak-rental service actually returned, and it builds match criteria from what the client actually sent — no more, no less. Every judgement about which parts are the contract and which are that afternoon's accidents is yours. Left to individual developers, that judgement is made differently every time, and the symptom is not one bad mapping set but an estate of them: some over-matched and flaky, some carrying credentials, some ten times larger than they need to be, none of them comparable. The leverage point is that WireMock funnels all of it through one object. ## The levers WireMock actually gives you In WireMock, `recordSpec()` builds the specification passed to `startRecording(...)` or `snapshotRecord(...)`. The controls worth standing behind are: - **WireMock's `captureHeader("X-Kayak-Site")`** — names a request header that becomes part of the recorded mapping's match criteria. This is an allow-list by construction: headers you do not name do not participate. - **WireMock's `extractTextBodiesOver(...)`** — the byte threshold above which a response body is written out as a separate body file under `__files` and referenced from the mapping rather than inlined. - **WireMock's `extractBinaryBodiesOver(...)`** — the same decision for binary payloads, which you almost never want inline. - **WireMock's `ignoreRepeatRequests()`** — tells the recorder to drop duplicate requests instead of doing anything clever with them, which is usually what you want for a client that polls. - **WireMock's `--match-headers`** — the launcher-flag equivalent of `captureHeader` for a standalone recorder, so the same policy can be expressed to a container as well as to a fixture. - **WireMock's `--print-all-network-traffic`** — not a capture control at all, but the thing you check a session against, because it shows what crossed the server rather than what survived conversion. ## Headers are the lever that bites Header capture is where the instinct and the correct answer diverge. Capturing everything feels safe and is the opposite: 1. Every captured header becomes a **match criterion**, so the recorded mapping now demands that header at that value. 2. A `User-Agent`, a correlation identifier or a bearer token differs on the next run, so the kayak-rental call that recorded cleanly stops matching and falls through to nothing. 3. The failure surfaces as an unmatched request in an unrelated test, weeks later, and reads as flakiness rather than as an over-specified fixture. So the policy is an allow-list of headers that genuinely change the upstream's answer — a site code, a content type, an API version header — and nothing else. If a header does not change the response, capturing it can only make the stub more brittle. ## Bodies, repeats and set size The other two levers are about the set staying legible: - Extraction thresholds decide whether a mapping file is readable in review. A mapping with a fifty-kilobyte inlined availability payload is not something anyone reads, and unreadable mappings are unreviewed mappings. - Repeat handling decides whether a polling client dominates the set. A kayak-rental dashboard that hits `GET /availability?site=lower-weir` every two seconds during a five-minute manual session can leave more mappings behind than the rest of the API combined. Both are cheaper to set once, in the spec, than to fix afterwards by deleting files. ## The half that is not technical The controls above shape what is captured. They do nothing about what is *kept*, and that is the part a standard has to state: - **Nothing recorded is committed unread.** The recorder cannot distinguish a contract from a credential, so a human must. - **Recording against a live upstream is a named activity**, not something anyone does casually — it puts real traffic through a real service and pulls real data back onto a laptop. - **A capture is dated by construction.** Whatever the kayak-rental service returned at the moment of capture is now frozen, and everyone reading the set later should know that. ## What to actually write down A workable standard fits on one page and names four things: the shared WireMock `recordSpec()` every suite uses, the header allow-list it encodes, the review step between recording and commit, and who is permitted to point a recorder at production. Mountebank teams reach the same place through different machinery — `recordRequests` per imposter rather than a shared specification object — but the governing question is identical: **the recorder decides nothing, so somebody has to.**