In REST Assured, why does then().contentType(ContentType.JSON) accept a vendor +json media type?

## Three overloads, three different comparisons `ValidatableResponseOptions` declares `contentType(ContentType)`, `contentType(String)` and `contentType(Matcher<? super String>)`. They all read the response's `Content-Type`, and they are deliberately not equally strict: | overload | what it compares | passes on `application/vnd.kayak.v2+json` | |---|---|---| | `contentType(ContentType.JSON)` | the media-type **family** the value resolves to | yes | | `contentType("application/json")` | a case-insensitive **prefix** of the value | no | | `contentType(equalTo("application/json"))` | the **raw** value, parameters included | no | ## Why the enum form accepts a vendor type When the argument is a `ContentType` constant, REST Assured does not compare strings. It resolves the actual value into a `ContentType` and compares the two enum constants. That resolution is a family lookup: 1. Any media-type parameters are dropped — everything from the first `;` onward, so `;charset=utf-8` never participates. 2. The remainder is lower-cased and checked against each constant's own media-type list. For `JSON` that list is `application/json`, `application/javascript`, `text/javascript` and `text/json`. 3. Failing that, a **suffix rule** applies: anything ending in `+json` resolves to `JSON`, `+xml` to `XML`, and `+html` to `HTML`. Rule 3 is the answer to the question. `application/vnd.kayak.v2+json` is not in the list, but it ends in `+json`, so it resolves to `ContentType.JSON` and the assertion passes. So does `text/json`, and so does `application/json;charset=utf-8`. That is by design: the enum names a family of media types, and the same resolution decides which parser REST Assured will use for the body. ## Why `equalTo("application/json")` fails The `Matcher` overload hands your matcher the **raw** header value, exactly as received. Most services send a charset parameter, so the actual value is `application/json;charset=utf-8` and an equality matcher against `application/json` fails with: ``` Expected content-type "application/json" doesn't match actual content-type "application/json;charset=utf-8". ``` The `String` overload sits between the two. It strips spaces and tabs from both sides and then tests whether the actual value **starts with** the expected one, case-insensitively. So: - `contentType("application/json")` passes against `application/json;charset=utf-8`. - `contentType("application/json;charset=utf-8")` also passes, because the whole thing is a prefix of itself. - `contentType("json")` fails — a prefix means from the beginning, not anywhere. - `contentType("APPLICATION/JSON")` passes, because the comparison ignores case. ## The same four constants, spelled out It helps to know what the enum actually carries, because the family is wider than the name suggests: - `ContentType.JSON` — `application/json`, `application/javascript`, `text/javascript`, `text/json`, plus anything ending in `+json`. - `ContentType.XML` — `application/xml`, `text/xml`, `application/xhtml+xml`, plus anything ending in `+xml`. - `ContentType.HTML` — `text/html`, plus anything ending in `+html`. - `ContentType.TEXT` — `text/plain` only; a value such as `text/csv` resolves to no constant at all and therefore fails every enum comparison. A value that resolves to nothing is simply unequal to whatever constant you named, so the failure message shows the constant's name against the raw header value and reads a little oddly the first time you see it: ``` Expected content-type "JSON" doesn't match actual content-type "text/csv". ``` ## Choosing strictness on purpose - Use `ContentType.JSON` when the claim is "a client can parse this as JSON". It survives a charset change and a move to a versioned vendor type, which is usually what you want and occasionally the bug. - Use `contentType("application/vnd.kayak.v2+json")` when the exact media type **is** the contract — a versioned type that a consumer negotiates on is a promise, and the prefix comparison still lets the charset ride along. - Use `contentType(Matcher)` when you need something the other two cannot express: `startsWith`, `containsString`, or an exact `is("application/json;charset=utf-8")` including parameters. - Use `header("Content-Type", ...)` only when you deliberately want the plain header path; the dedicated method exists because the media type also drives body parsing. The production lesson is that a green `contentType(ContentType.JSON)` is not evidence that the media type is unchanged. If a kayak-rental endpoint moves from `application/json` to `application/vnd.kayak.v2+json`, every enum-form assertion in the suite stays green while consumers that negotiated the old type break. If that transition is one your tests must catch, name the exact type in a `String` or `Matcher` assertion for the endpoints whose media type is part of the published contract, and keep the tolerant enum form for the rest. A cheap belt-and-braces habit on the handful of endpoints whose media type is negotiated: assert both, the enum form for the family and a `String` form for the exact type, so the first tells you the payload is still parseable and the second tells you the moment the published type moved.