In a Karate feature file, what body does each of `request`, `form field` and `multipart field` build, and what `Content-Type` does each send when you never set that header yourself?

## Three keywords, three bodies | Keyword | Body it builds | Default `Content-Type` | |---|---|---| | `request` | the evaluated value, as-is | inferred from the value's type | | `form field` / `form fields` | accumulated key/value pairs | `application/x-www-form-urlencoded` | | `multipart field` / `multipart file` / `multipart entity` | accumulated parts | `multipart/form-data; boundary=...` | They are not interchangeable spellings of "set the body". Choosing the wrong one is a wire-format mistake that a server usually answers with a 415 or a 400, and the step itself gives no hint. ## `request` and the inferred content type The most-used Karate idiom is to write the body as inline JSON with unquoted keys and let the type do the work: ```gherkin Given url 'https://api.example.com' And path 'cats' And request { name: 'Billie', type: 'LOL' } When method post Then status 201 ``` No `Content-Type` header was set, and the request still goes out as JSON. The rule is a plain mapping from the runtime type of the body value: - a map or a list — `application/json` - a string — `text/plain` - an XML node — `application/xml` - a byte array — `application/octet-stream` - anything else — no inferred type This is why setting the header explicitly is usually unnecessary, and why it is essential in one case: a body that *is* a string but must be sent as something else. `request '{"name":"Billie"}'` — quoted, so a string — infers `text/plain`. If the server insists on `application/json`, either drop the quotes so it evaluates to a map, or set the header yourself. The body value is an expression, so `request read('cat.json')`, `request myVariable` and inline XML all work the same way. Setting the header yourself always wins: the inference runs only when no `Content-Type` is already present on the request, so an explicit `header Content-Type = 'application/vnd.api+json'` step suppresses it entirely. That is the escape hatch for a service that insists on a vendor media type. ## `form field` versus `multipart field` Both accumulate named values, and both are additive — each step adds one entry, so several steps build one body: ```gherkin Given path 'oauth', 'token' And form field grant_type = 'client_credentials' And form field scope = 'cats.read' When method post Then status 200 ``` That sends `grant_type=client_credentials&scope=cats.read` as `application/x-www-form-urlencoded`. Swapping those two steps to `multipart field` sends the same names as parts of a `multipart/form-data` body with a generated boundary — a different wire format that a token endpoint will reject. The pair share one underlying part builder, and the builder is created by whichever keyword touches it first, with the multipart flag already decided. **Mixing `form field` and `multipart field` in one call does not produce a hybrid**: the first keyword used chooses the encoding for the whole body, and the later steps just add entries to it. If you find both spellings in one scenario, that is a bug to fix, not a style choice. `multipart file` is the variant for an attachment; it takes a map so that the part can carry a filename and its own content type alongside the value, which is what a file upload needs and a plain field cannot express. ## The GET drain One behaviour surprises people who reuse a block of steps across verbs. When the request is finally built, if the verb has resolved to **GET** and form fields are present, those fields are moved into the query string and the form body is dropped. So a block of `form field` steps that posts correctly will, on `method get`, quietly send `?grant_type=client_credentials&scope=cats.read` and no body at all. The related default: if no `method` step ran but multipart parts are present, the verb defaults to POST rather than GET — the only case where the verb is inferred rather than stated. ## Choosing between them 1. Sending a JSON or XML document — `request`, and let the type infer the header. 2. Sending an HTML-form-style payload, most often a token or login endpoint — `form field`. 3. Uploading a file, or mixing a file with metadata fields — `multipart file` plus `multipart field`. And whichever you pick, remember that the body, the form parts and any explicit `Content-Type` header are all cleared once the call fires. A second call in the same scenario has to build its body again from scratch.