In REST Assured, why must given().contentType(...) come before body(diveEntry) in the chain?

## Serialization happens inside the `body(...)` call REST Assured's fluent chain looks declarative, as if the whole specification were assembled first and then executed. `body(Object)` breaks that impression. When you call it, it immediately asks the object-mapping layer for a `String`, stores that string as the request body and returns. By the time the chain reaches `post(...)`, the bytes have existed for several statements. The content type the mapping layer receives is read at that same instant, from the `Content-Type` header already on the specification. So the two chains below are not two spellings of one request: - `given().contentType(ContentType.XML).body(entry)` — the header is present, the XML branch runs. - `given().body(entry).contentType(ContentType.XML)` — the header is not present yet, so the mapping layer is handed a null content type and takes the no-content-type branch. ## What the wrong order actually sends The no-content-type branch is not an error path. It has a defined order of its own and will happily produce a payload: 1. It walks Jackson 3, Jackson 2, Jackson 1, Gson, Jakarta EE, JAXB, Johnzon, Yasson. 2. It stops at the first candidate whose marker class is on the classpath. 3. It throws only if none of the eight is present. On any ordinary dive-log project Jackson is on the classpath, so step 2 stops at Jackson and the body becomes JSON. The later `contentType(ContentType.XML)` call cannot undo that — it only writes a header. The request that goes out is JSON bytes under an `application/xml` header, which the service rejects. Nothing in the test points at the mapper; the symptom is a rejected request that looks correct in the source. ## The three orders, side by side | when `body(Object)` runs, the content type is | branch taken | order tried | |---|---|---| | something containing `json` | JSON | Jackson 3, Jackson 2, Jackson 1, Gson, Johnzon, Yasson | | something containing `xml` | XML | Jakarta EE, JAXB | | absent, or exactly `*/*` | neither | Jackson 3, Jackson 2, Jackson 1, Gson, Jakarta EE, JAXB, Johnzon, Yasson | | anything else | none | throws `IllegalArgumentException` | The third row is the one that catches people. It is not the JSON order followed by the XML order: Jakarta EE and JAXB sit ahead of Johnzon and Yasson in it. A project with only Johnzon and JAXB available and no content type set will serialize to **XML**, which is rarely what the author meant. ## The charset is resolved at the same moment Mapper selection is not the only thing the content type decides in that instant. `body(Object)` also resolves the charset it hands to the mapper, and it does so from the same header: - If the content type carries a `charset=` parameter, that charset is used. - Otherwise `EncoderConfig` is consulted for a default registered against that content type — `application/json` maps to UTF-8 out of the box. - Otherwise the config's `defaultContentCharset()` applies, and that default is ISO-8859-1. So `given().body(entry).contentType("application/json; charset=UTF-16")` misses twice: the writer is chosen by the no-content-type scan *and* the payload is encoded as ISO-8859-1, because neither the declared charset nor the `application/json` default was visible when the mapping ran. Written the other way round, both land. A dive site name with a non-ASCII character is the usual way this second half of the bug is discovered. ## Making it not happen Ordering discipline is the whole fix, and there are three ways to get it for free: - Put `contentType(...)` immediately after `given()` as a house style, so no chain can ever set a body first. - Set the content type once in a shared request specification that every call starts from, so the header is already on the specification before any per-test `body(...)` runs. - Name the mapper explicitly with `body(entry, ObjectMapperType.JAKARTA_EE)` where the format genuinely matters, which removes the content type from the decision entirely. A review habit helps too: in any chain that calls `body(...)` with an object, check that a content type was established earlier in that same chain. ## Where the hazard stops Two of the three object-taking overloads are immune, for different reasons: - `body(Object, ObjectMapperType)` short-circuits the content-type decision. The content type still travels to the mapper as context — it is visible through `ObjectMapperSerializationContext.getContentType()` — but it no longer chooses anything, so the payload is identical whichever order you write. - `body(Object, ObjectMapper)` serializes through the instance you pass and never consults the content type for selection at all. It also does not apply to the byte-carrying overloads: `body(String)`, `body(byte[])`, `body(File)` and `body(InputStream)` have nothing to serialize, so their position in the chain is irrelevant to the payload. The trap is specific to `body(Object)`, which is exactly the overload people reach for most often when posting a dive log.