In REST Assured, an endpoint returns JSON as text/plain and as(ScaffoldInspection.class) fails — how do you fix it?

A legacy endpoint on a scaffolding-inspection API answers `GET /inspections/INSP-2024-0917` with a perfectly good JSON body and the header `Content-Type: text/plain`. `extract().as(ScaffoldInspection.class)` blows up. Nothing is wrong with the body, the DTO or the classpath — the response label is what fails. ## How REST Assured picks a response reader Deserialization is driven by the **response's** content type, the mirror image of serialization, which is driven by the request's. When `as(Class)` runs, REST Assured resolves a content type and then makes a substring decision on it: - If the resolved content type contains `json`, it walks the JSON mappers on the classpath and uses the first one it finds. - If it contains `xml`, it does the same for the XML mappers. - Otherwise it falls back to the default parser's content type, if one was set. - If that too comes up empty, it throws `IllegalStateException: Cannot parse object because no supported Content-Type was specified in response. Content-Type was 'text/plain'.` The substring test explains a lot of otherwise puzzling behaviour. A vendor type such as `application/vnd.scaffold.inspection+json` needs no configuration at all, because it contains `json`. `text/plain` does not, and neither does `application/octet-stream` — and `Parser.TEXT` exists but has no object mapper behind it, so recognising a body as text is not the same as being able to map it. ## The three levers, and their blast radius | Lever | Scope | Effect | |---|---|---| | `RestAssured.registerParser("text/plain", Parser.JSON)` | that one content-type string | the registrar rewrites the chosen type to `application/json`, so a JSON mapper is picked | | `RestAssured.defaultParser = Parser.JSON` | every response the registry does not otherwise recognise | supplies a fallback content type, including for responses with no `Content-Type` at all | | `as(ScaffoldInspection.class, ObjectMapperType.JACKSON_3)` | this one call | no content type is passed to the mapping step, so the header is never consulted | A fourth exists for the awkward cases: `as(ScaffoldInspection.class, myObjectMapper)` takes an `ObjectMapper` instance and calls it directly, bypassing the registry and the selection logic together. Ranked by preference in a real suite: 1. `registerParser` when exactly one endpoint or one vendor type misbehaves — it says what is wrong in one line and leaves every other response alone. 2. The two-argument `as(...)` when the fix should not outlive the test that needs it. 3. `defaultParser` when the service is consistently sloppy about labelling and you have decided the whole suite should treat unknown types as JSON. ## Why the default parser is the blunt instrument `RestAssured.defaultParser` is often described as "for responses with no content type", and that is its headline use. But the registrar returns the default parser for *any* content type that has no registered entry, so setting it globally quietly colours far more than the one endpoint you were fixing. If a second endpoint later starts returning XML, a suite-wide `Parser.JSON` default is now in a position to make a confusing failure instead of an obvious one. Prefer the narrow lever until you have a reason not to. ## Test hygiene around the statics Both `registerParser` and `defaultParser` are static state on `RestAssured`, which means they survive the test that set them and leak into every test that runs afterwards in the same JVM. That matters in a parallel or long-running suite: - Reset in teardown: `RestAssured.reset()` clears the default parser along with `baseURI`, `port`, the request and response specifications, the filter list and the config. - Or `RestAssured.unregisterParser("text/plain")` to remove one registration without flattening everything else. - Or avoid the statics: `ResponseSpecBuilder` exposes `registerParser(String, Parser)` and `setDefaultParser(Parser)`, so the rule travels with a response specification you attach where you want it. - The validate side has the same two spellings as `then().parser(String, Parser)` and `then().defaultParser(Parser)`. ## Diagnosing it when you are handed the failure The exception text names the offending content type verbatim, so the first move is to read it rather than the DTO. From there: - Print the response headers — `then().log().headers()` — and confirm what the server actually sent, including any charset suffix. - Check whether the body assertions in the same test were also failing. If `body("verdict", equalTo("PASS"))` was fine but `as(...)` was not, you are looking at a mapping-side problem, not a parsing-side one. - Decide whether the real fix belongs in the test suite at all. A service labelling JSON as `text/plain` is a defect in the service; the parser registration is a workaround you are choosing to carry, and it is worth saying so in the pull request rather than burying it in a base class. That last judgment is what separates a senior answer from a correct one. All three levers work. Choosing the narrowest one, keeping the global state clean, and naming the underlying service bug is the part that does not come from the documentation.