In a saved Postman collection file, what does a request's body.mode field select, and where does the payload sit?
answer
- One field decides the payload's shape
- A tagged union, not a free-form bag
- The payload key repeats the tag's name
- raw, urlencoded, formdata, file, graphql
basics
~10 sbody.mode names one of raw, urlencoded, formdata, file or graphql, and the payload sits under a key spelled the same as the mode. Only that one key is read.
solid answer
~40 sA request's `body` in a collection file is a tagged union. `body.mode` carries exactly one of `raw`, `urlencoded`, `formdata`, `file` or `graphql`, and the payload lives under the key of that same name — `mode` of `formdata` means the entries sit under `body.formdata`. `raw` holds one string; `urlencoded` and `formdata` hold lists of entries; `file` references a file on disk instead of inlining bytes; `graphql` holds that mode's payload. Because `mode` is the selector, editing a request from one shape to another can leave the previous key behind in the file — it is inert text and never reaches the wire. When you read a stored request, read `mode` first, then only the key it names.
code
json · 10 lines{
"name": "Create order",
"request": {
"method": "POST",
"body": {
"mode": "raw",
"raw": "{\"sku\":\"A-1\",\"qty\":2}"
}
}
}go deeper
Be ready to name the five values of mode and say that the payload sits under the key of the same name. That one sentence answers most screening versions of this question.
Explain the union mechanically: the tag selects the key, sibling payload keys are inert, and no header or payload text can retag the body. Show how you would read a stored request in order.
Show what this costs in a long-lived document — stale payload keys surviving a shape change, diffs that edit a dead key, and file-referencing payloads that make a run depend on the machine it runs on.
Own the review policy: treat a mode change as a behaviour change, require stale payload keys to be deleted rather than deprecated, and decide how shared collections declare payloads so runs are reproducible off the authoring machine.
## The `body` object is a tagged union A request stored in a collection file may carry an optional `body` object, and that object is a **tagged union**: one field, `mode`, names which shape the payload takes, and the payload itself sits under a key spelled exactly like the mode. These names belong to the **collection format** — the file declares them, and every program that reads the file agrees on them because the format says so, not because one editor chose to behave that way. The values `mode` may take are `raw`, `urlencoded`, `formdata`, `file` and `graphql`. There is no sixth value, and there is no "auto" or "detect" setting: a stored request states its payload shape outright. ## The modes and the key each one names | `mode` | payload key | what that key holds | |---|---|---| | `raw` | `body.raw` | one string, sent as written | | `urlencoded` | `body.urlencoded` | a list of key/value entries encoded as a form | | `formdata` | `body.formdata` | a list of entries, each one text or a file | | `file` | `body.file` | a reference to a file on disk rather than inline bytes | | `graphql` | `body.graphql` | the payload the `graphql` mode carries | Two consequences fall straight out of that table: - **The key repeats the mode name**, so you never have to guess where the payload lives. Read `mode`, then read the key it spells. - **Only the named key is read.** A `body` object can physically hold more than one payload key, and the one `mode` names is the one that reaches the wire. ## Why the union shape matters The second point is the one interviewers push on, because it is where intuition goes wrong. Editing a request from one shape to another does not necessarily erase the shape you left behind; a document can end up carrying a `raw` string *and* a `formdata` list while `mode` says `formdata`. Nothing is ambiguous — the tag decides — but a reader who scans the object for "the payload" and finds the wrong key will describe a request that is not the request that runs. The same reasoning applies in the other direction. A payload key with no matching `mode` is dead text in the document: it costs bytes, it shows up in diffs, and it sends nothing. When you review a collection under version control, a change to `mode` is a far bigger change than a change to any single payload key, because it moves which key is live. Two further things the union does **not** do: - It does not derive the shape from a header you typed. A `Content-Type` header on the request is a header; it does not retag the body. - It does not derive the shape from the payload's own text. A `raw` string that happens to look like form pairs is still sent as a raw string. ## Reading a stored request in order 1. Find `body` on the request. If it is absent, there is no payload to reason about. 2. Read `body.mode` and note the single name it carries. 3. Read the key spelled with that name — that is the payload, and nothing else in `body` is. 4. Read the request's header list separately, because headers are declared there and are not implied by the mode alone. Doing those four steps in that order takes seconds and settles arguments that otherwise run long, especially on a document that several people have edited by hand. ## What the `file` and `graphql` modes are here `file` is the mode whose key points at a file on disk instead of inlining its bytes. The practical effect is that the document stays small and portable while the run needs that path to exist wherever the run happens — a collection that works on the machine that authored it can fail elsewhere purely because the referenced file is not there. `graphql` is, in this subject, a value of `mode` and the name of the key that holds its payload. What the GraphQL language itself means, how a query is written, and how a server answers one are a separate subject entirely and are not part of reading a stored body. ## Where this subject stops - **Media types and content negotiation** — what a particular type means to a server, and how a server chooses among several — are HTTP's own subject, not the body object's. - **A definition document's request body** — how an API description declares payloads and encodings — is a different artefact with different field names. - **Turning an object into a payload from a test harness in another language** is that harness's subject. The body object's contribution is narrow and worth stating precisely: one tag, one payload key, and a strict rule that the tag picks the key.
- If a body object holds a raw string but mode says formdata, what actually goes on the wire?The `formdata` entries. `mode` is the selector, so only the key it names is read; the leftover `raw` string is inert text in the document. It costs bytes and shows up in diffs, but it sends nothing. The right treatment is to delete it rather than edit it.
- Which mode sends the contents of a file on disk, and what does the collection document actually store?The `file` mode. Its key holds a reference to a file rather than the file's bytes, so the document stays small and portable. The trade is that the run depends on that file existing wherever the run happens, which is why such a request can pass on the authoring machine and fail on a shared one.
It behaves like a tagged union in code: one tag field says which member is live, and reading a different member gives you a value nobody meant to send.
saying these in an interview costs you the question
- Thinks a Content-Type header chooses the body's shape
- Assumes every payload key present in the object is sent
- Calls body a free-form object with arbitrary payload keys
- Believes file mode inlines the file's bytes into the document
- Expects the runtime to detect the shape from the payload text