A REST Assured suite repeats the same base URI, headers and auth in every test, and when a test fails in CI the output shows only a matcher mismatch. What features of the library would you use to fix both problems?

## The two problems are independent Repetition is a maintenance problem; opaque failures are an operability problem. REST Assured has a distinct mechanism for each, plus a third — filters — that spans both. ## Specifications kill the repetition A `RequestSpecification` is a reusable bundle of request configuration. Build it once: ```java RequestSpecification apiSpec = new RequestSpecBuilder() .setBaseUri(System.getProperty("api.baseUri", "http://localhost:8080")) .setBasePath("/api/v1") .setContentType(ContentType.JSON) .setAccept(ContentType.JSON) .addHeader("X-Client", "api-tests") .setAuth(RestAssured.preemptive().basic(user, pass)) .addFilter(new RequestLoggingFilter(LogDetail.ALL)) .build(); ``` and apply it per test with `given().spec(apiSpec)`. Anything you add after `spec(...)` is layered on top, and later settings win for single-valued properties, so a test can override the content type or add a header without touching the shared spec. Specs are also composable: `new RequestSpecBuilder().addRequestSpecification(apiSpec).setAuth(adminAuth).build()` produces an admin variant without duplication. `ResponseSpecification` is the mirror image for expectations: ```java ResponseSpecification okJson = new ResponseSpecBuilder() .expectStatusCode(200) .expectContentType(ContentType.JSON) .expectResponseTime(lessThan(2000L)) .build(); given().spec(apiSpec).when().get("/users").then().spec(okJson).body("size()", greaterThan(0)); ``` This is worth more than it first looks: a shared response spec makes suite-wide policy ("every successful read returns JSON in under two seconds") a single edit rather than a hundred. ## Why specs beat the static globals `RestAssured.baseURI`, `RestAssured.port`, `RestAssured.authentication`, `RestAssured.requestSpecification` and friends are **static mutable state on a shared class**. Setting them in per-test setup works until: - one test mutates a global and does not reset it, and an unrelated test fails depending on execution order; - tests run in parallel and stomp on each other's globals — the statics are not per-thread; - someone reads a test in isolation and cannot tell what base URI it hits. If you do use the globals (they are convenient for a single-module suite), set them in one place in suite setup and call `RestAssured.reset()` in teardown. Explicit `given().spec(...)` is safer and self-documenting, and it is the only workable option under parallel execution. ## Logging: quiet on green, complete on red The default failure message names the path, the expected matcher and the actual value — enough when the value is wrong, useless when the request itself was wrong (bad URL, missing header, unexpected content type). The targeted fix: ```java given().spec(apiSpec).log().ifValidationFails() .when().get("/users/{id}", id) .then().log().ifValidationFails() .statusCode(200); ``` The request-side call buffers the outgoing request and prints it only if a `then()` assertion fails; the response-side call does the same for the response. Suite-wide, `RestAssured.enableLoggingOfRequestAndResponseIfValidationFails(LogDetail.ALL)` (or `.addFilter(new ErrorLoggingFilter())`) sets the same behaviour once. `log().all()` prints unconditionally — fine while developing a test, terrible in CI where it buries the real failure in megabytes of output. Before turning logging on, blacklist secrets: ```java RestAssured.config = RestAssured.config() .logConfig(LogConfig.logConfig().blacklistHeader("Authorization")); ``` otherwise every CI run publishes a bearer token to a log aggregator. ## Filters: the extension point A `Filter` sees every request and response and can modify either: ```java public class CorrelationIdFilter implements Filter { @Override public Response filter(FilterableRequestSpecification req, FilterableResponseSpecification res, FilterContext ctx) { req.header("X-Correlation-Id", UUID.randomUUID().toString()); return ctx.next(req, res); } } ``` Typical uses: injecting or refreshing an auth token (retry once on a 401 with a fresh token), stamping a correlation id so a failed test can be traced in server logs, recording every exchange into the test report or an HTML attachment, and timing/metrics. The built-in `RequestLoggingFilter`, `ResponseLoggingFilter` and `ErrorLoggingFilter` are ordinary filters you can add to a spec. Because filters live on the specification, adding one to the shared `apiSpec` applies it to the whole suite from one line. A filter that forgets to call `ctx.next(req, res)` short-circuits the chain and the request is never sent — a confusing failure worth knowing about. ## Putting it together A healthy suite has: one place that builds the request spec from environment configuration, one or two response specs encoding shared expectations, failure-only logging enabled globally with secrets blacklisted, and a small set of filters for auth and traceability. Individual tests then contain only what is specific to the endpoint under test — which is also what makes the failure message meaningful when one goes red at 3am in CI.