In REST Assured, how do you change the JSON schema draft or switch off checked validation?

## Two scopes, one settings object REST Assured's schema matcher is a thin wrapper, so both questions in the title are really questions about the library it wraps. The bridge is `io.restassured.module.jsv.JsonSchemaValidatorSettings`, which carries exactly three things: a `JsonSchemaFactory`, a `checkedValidation` flag, and a `parseUriAndUrlsAsJsonNode` flag. Construct one with the static factory `settings()`, or with `new JsonSchemaValidatorSettings()`, and chain through the no-op readability methods `and()` and `with()`, which both return `this`. You can apply that object at two scopes. - **One assertion.** `matchesJsonSchemaInClasspath(...)` returns a `JsonSchemaValidator`, which declares `using(JsonSchemaFactory)` and `using(JsonSchemaValidatorSettings)`. Both build a fresh matcher and return it as a `Matcher<?>`; neither touches anything global. - **Every matcher created from now on.** `JsonSchemaValidator.settings` is a **public static field**. Assign it and each subsequent `matchesJsonSchema*` call picks it up; `JsonSchemaValidator.reset()` sets it back to `null` and the defaults return. ## Choosing the draft REST Assured has no draft enum of its own — searching for one is a dead end. The default version is configured on the wrapped library's factory, and passed in: ```java JsonSchemaFactory draftV4 = JsonSchemaFactory.newBuilder() .setValidationConfiguration(ValidationConfiguration.newBuilder() .setDefaultVersion(DRAFTV4) // constant from the wrapped library .freeze()) .freeze(); get("/surveys/PEAT-2291").then() .body(matchesJsonSchemaInClasspath("schemas/carbon-survey-schema.json").using(draftV4)); ``` The default, when you configure nothing, is `JsonSchemaFactory.byDefault()`. Whatever drafts that factory understands are the drafts your assertions understand — which is why the artifact version of the wrapped library, not the REST Assured version, is what to check when a schema keyword behaves unexpectedly. ## Checked versus unchecked validation The wrapped library offers two validation calls, and `checkedValidation` picks between them: `true` (the default) uses the checked call, `false` uses the unchecked one. REST Assured's matcher reads the flag through `shouldUseCheckedValidation()` at match time and dispatches accordingly. Set it per assertion with `.using(settings().with().checkedValidation(false))`, or globally on the static field. Treat it as a choice about **how a processing problem is raised**, not as a switch that turns a schema mismatch into a pass — a payload that violates the schema still fails either way. ## The settings object is immutable This catches people who expect a JavaBean: - `checkedValidation(boolean)` returns a **new** `JsonSchemaValidatorSettings`. - `jsonSchemaFactory(JsonSchemaFactory)` returns a **new** instance. - `parseUriAndUrlsAsJsonNode(boolean)` returns a **new** instance. - `and()` and `with()` return `this` and exist only so the chain reads as a sentence. - The constructor rejects a `null` factory with `IllegalArgumentException`. So `JsonSchemaValidatorSettings s = settings(); s.checkedValidation(false);` changes nothing at all — the new object is discarded. Always keep the return value: `s = s.checkedValidation(false);`, or build the whole thing in one chain. The same immutability is why `matcher.using(factory)` is safe: internally it calls `instanceSettings.jsonSchemaFactory(factory)`, producing a new settings object for that one matcher and leaving the static field untouched. ## The static field is shared mutable state `public static JsonSchemaValidatorSettings settings;` is as blunt as it looks, and three consequences follow: 1. **It is read when a matcher is created, not when it validates.** A matcher built before you assign the field keeps the defaults, and one built while the field is set keeps that configuration even if you reset afterwards. 2. **It leaks across tests.** Nothing scopes it to a class or a method, so a test that sets it and does not clean up changes every later assertion in the JVM. 3. **It is not thread-safe.** There is no synchronisation, so two test classes running in parallel and configuring it differently will interleave unpredictably. The defensible pattern is one of two extremes. Either the whole suite genuinely wants the same configuration — set it once in a suite-level fixture and never touch it again — or configuration is per-case, in which case use `.using(...)` on the individual assertion and leave the static alone. The unstable middle is a test that sets the static for its own benefit; if you must, pair it with `JsonSchemaValidator.reset()` in teardown. ## The third setting, briefly `parseUriAndUrlsAsJsonNode` (default `false`) decides how a schema named by `URL` or `URI` is handed on. Left `false`, the URL's string form goes to the factory, which dereferences it as a URI; set `true`, REST Assured loads the document into a node first and passes that. This matters for `matchesJsonSchemaInClasspath`, because that method funnels into the `URL` overload — so a classpath schema takes the URI route by default.