In REST Assured, how do given().body()'s String, byte[], File and InputStream overloads differ?

## The four raw overloads `RequestSpecification` declares seven `body` overloads. Four are *raw* — `body(String)`, `body(byte[])`, `body(File)` and `body(InputStream)` — and each one does exactly two things: reject a `null` argument, then assign it to the specification's request body. Nothing is parsed, nothing is converted, and no `ObjectMapper` is consulted. The remaining three take an `Object` and hand it to a mapper, which is a separate topic with its own rules. The null check is literal and shared: all four route through the same helper, so `given().body((File) null)` throws `IllegalArgumentException` with the message `body cannot be null` rather than quietly sending nothing. Because these are ordinary Java overloads, **the static type of the expression picks the method at compile time**. Assigning a JSON string to an `Object` variable first and then calling `body(thatVariable)` binds to `body(Object)` and runs a mapper over it, which is a different code path from the one you thought you were on. ## What Content-Type each one produces When the request carries no explicit content type, REST Assured derives one from the shape of the body. For a falconry weight-log API this is what a `PUT` of a raw payload sends: | body argument | derived Content-Type when you set none | | --- | --- | | `body(weighInJson)` (a `String`) | `text/plain; charset=ISO-8859-1` | | `body(new File("scale-2026-09-07.jpg"))` | `text/plain; charset=ISO-8859-1` | | `body(photoBytes)` | `application/octet-stream; charset=ISO-8859-1` | | `body(new FileInputStream(photo))` | `application/octet-stream; charset=ISO-8859-1` | Three points follow from that table: - `byte[]` and `InputStream` are the only two shapes REST Assured recognises as binary. A `File` is not one of them, so it falls through to the text branch. - The `; charset=` suffix is `EncoderConfig`'s default content charset, which is `ISO-8859-1`. It is appended even to `application/octet-stream`, which surprises most people the first time they read a request log. - A JSON body sent as `body(jsonString)` with no `contentType(ContentType.JSON)` goes out as `text/plain`, and most services answer that with a 415 rather than parsing it. ## Why the `File` default is a real trap The derived content type does not just decorate the request — it selects the encoder. Under a binary content type the payload is streamed: a `File` is opened as a `FileInputStream` and wrapped with its known length, and an `InputStream` is passed through as it is. Under a *text* content type the encoder takes a different branch and **reads the whole `File` into a `String`** using the charset from the content type, then sends that string. For a CSV of hawk weights that is harmless. For a scale photograph it is not: the bytes are decoded as ISO-8859-1 text and re-encoded, and the server receives a corrupted image with no error anywhere in the chain. The fix is one call: ```java given().contentType(ContentType.BINARY) // or "image/jpeg" .body(new File("scale-2026-09-07.jpg")) .when().put("/hawks/HW-118/weigh-ins/WI-9032/scale-photo") .then().statusCode(204); ``` Set the real media type whenever the body is a `File` or an `InputStream` and you never meet this. ## Body versus form parameters, and body versus parts Two combinations behave in ways worth knowing before you hit them: 1. **Form parameters and a body together** on a body-bearing method raise `IllegalStateException` with the message `You can either send form parameters OR body content in POST, not both!`. The check runs before anything is sent, so the failure is immediate and readable. 2. **A body and `multiPart(...)` together** fail silently instead. Once the part list is non-empty the assembled body content becomes an empty byte array, and the multipart encoder rebuilds the payload from the parts alone — your `body(...)` argument never leaves the process. The asymmetry is worth remembering: one conflict shouts, the other does not. ## A checklist for choosing an overload - Sending JSON or XML you already have as text? `body(String)` plus an explicit `contentType(...)`. - Sending bytes you built in the test? `body(byte[])` — the type is already right. - Sending a fixture from disk? `body(File)` **plus** `contentType(...)`, always. - Streaming something large or generated? `body(InputStream)`, remembering the stream is consumed once and cannot be replayed by a retry you write around the call. - Sending a domain object? That is `body(Object)`, a different overload family with mapper rules of its own. The rule that ties them together is short: the raw overloads never transform your argument, but the content type you do or do not set decides how it reaches the wire.