In REST Assured, how does a custom filter change the response before then() validates it?

## The response you were handed cannot be edited `io.restassured.response.Response` is an interface of readers — `asString()`, `asByteArray()`, `getStatusCode()`, `getStatusLine()`, `getHeaders()`, `getDetailedCookies()`, `jsonPath()` — with no public mutators anywhere on it. So "changing the response" from inside a filter never means setting a field on the object `ctx.next(requestSpec, responseSpec)` returned. It means producing a **different** `Response` and returning that one instead, and `io.restassured.builder.ResponseBuilder` is the class that exists for exactly this job. That design is deliberate rather than an oversight. A filter is around advice: the response object it receives is the value flowing back out of the chain, and letting one link quietly mutate a shared object would make the value seen by the next link depend on execution order in a way nobody could read from the call site. Returning a new object keeps the flow explicit — whatever you return **is** the response from this point outwards, and whatever you do not return is discarded. ## The clone, set, build shape ```java Response original = ctx.next(requestSpec, responseSpec); String masked = redactKeeper(original.asString()); return new ResponseBuilder().clone(original).setBody(masked).build(); ``` - `clone(original)` copies everything you are *not* changing: the content, content type, headers, cookies, status code and status line, plus internal wiring — the `RestAssuredConfig`, the decoder config, the session-id name and the response-parser registry — that lets `then().body(...)` parse the payload at all. - `setBody(...)` takes a `String`, a `byte[]` or an `InputStream`, and each overload rejects `null` with an `IllegalArgumentException` rather than quietly emptying the response. - `setHeaders(Headers)`, `setHeader(name, value)`, `setCookies(Cookies)`, `setContentType(String|ContentType)`, `setStatusCode(int)` and `setStatusLine(String)` cover the rest of the surface. - `build()` produces the `Response` you return from `filter(...)`. - The builder is a plain object with no link back to the chain, so it is safe to construct one per invocation; do not hold one in a field of the filter and reuse it across requests. Skipping `clone(...)` is the classic first-attempt bug. A bare `new ResponseBuilder().setBody(json).build()` returns a response carrying **only** what you set — no headers, no status line, none of the original's parsing configuration — so assertions that passed a minute ago start failing for reasons that have nothing to do with the lighthouse service. ## Where the rebuilt response lands Validation runs after the whole chain has unwound. `then().statusCode(200).body("lampStatus", equalTo("LIT"))` is applied to whatever the outermost filter returned, and `extract()` hands out that same object. To the test, a rebuilt response is indistinguishable from one the service sent. | you want to change | what you call | what `clone(...)` still carries | |---|---|---| | the payload | `setBody(String\|byte[]\|InputStream)` | status code, status line, headers, cookies | | a header | `setHeader(name, value)` or `setHeaders(Headers)` | body, status, cookies, parsing config | | the status | `setStatusCode(int)`, `setStatusLine(String)` | body, headers, cookies, parsing config | | nothing (short-circuit) | build a response and never call `ctx.next(...)` | nothing — you own every field | That last row is a different operation from the other three. Rebuilding happens **after** `ctx.next(...)` and edits a real answer from the service; short-circuiting happens **instead of** `ctx.next(...)` and means no request was ever made. ## What the rest of the chain sees Filters nest, so a rebuild is not private to the filter that performs it. The response your filter returns is the value its own caller receives from *its* `ctx.next(...)` call, which means every filter that ran earlier — and therefore sits outside yours — sees the rebuilt object rather than the original one, and may rebuild it again on the way out. Three consequences are worth holding on to: - A logging filter placed outside a rewriting filter prints the rewritten payload, not what arrived. - A rewriting filter placed outside another rewriting filter operates on the inner one's output. - Nothing anywhere keeps a copy of the untouched response, so if the original body matters for diagnosis you have to capture it inside the filter that first receives it. ## A worked lighthouse case `GET /lighthouses/{lighthouseId}` on the maintenance API returns `keeperOnDuty` with a real person's name in it, and the suite prints response bodies on failure. A filter that calls `ctx.next(...)`, rewrites `keeperOnDuty` to `REDACTED`, and returns `new ResponseBuilder().clone(original).setBody(masked).build()` keeps the name out of every artefact downstream of the filter, while `lighthouseId`, `lampStatus` and the 200 survive untouched because `clone(...)` carried them. ## When not to reach for it Rebuilding a response is a sharp tool, and the reasons to refuse it are worth saying out loud in a review: 1. **Never rebuild to make an assertion pass.** A filter that patches a missing field turns a real contract defect into a green run, and the next reader has no way to see it from the test. 2. **Never rebuild what the request could have avoided.** If the payload is wrong because the call was wrong, fix the call. 3. **Say so in the failure output.** A rewritten body that nobody expects is the hardest kind of test to debug, because the printed response and the served response differ. 4. **Keep the rewrite narrow.** Redaction, decompression of a bespoke envelope and normalising a known quirk are defensible; general body munging is not.