In a saved Postman collection, what two shapes can a request's url take, and why does the choice matter?
answer
- Two legal shapes, not one
- One flat value, or named parts
- raw sits beside the parts it summarises
- query is a list of entries
- Only named parts can be edited singly
basics
~20 sA collection stores a request's url either as one flat string or as an object of raw, protocol, host, path, port, query, hash and variable. Only the object form lets a tool address and edit a single part.
solid answer
~50 sThe collection file may store `request.url` as a **flat string** — the whole address in one value — or as an **object** whose members are `raw`, `protocol`, `host`, `path`, `port`, `query`, `hash` and `variable`. Both are legal, and both can appear in the same file, so any reader has to handle either. The object form is what you want in a document people edit: `query` is a list of entries with their own `key` and `value` rather than one encoded blob, `path` is its segments, and `variable` carries values for colon-prefixed segments. That makes one part addressable — change a single query entry and only that line moves in a diff — while a flat string can only be replaced wholesale or re-parsed by hand. `raw` is itself a member of the object, so the whole address is still readable at a glance.
code
json · 6 lines{
"name": "List orders",
"request": {
"url": "https://api.example.com/orders?status=open"
}
}go deeper
Recall that a saved request's address can be one plain string or an object with named parts, and be able to name a few of those parts — protocol, host, path, query.
Explain what each member of the url object holds, that raw sits inside the object beside the parts, and that query is a list of entries rather than one encoded string.
Show why a shared, version-controlled collection should keep addresses in the broken-down form: single-part edits, readable diffs, and safe machine rewrites across many requests.
Own the policy question — whether a team normalises every stored address to the structured form, what tooling enforces it on import and export, and what that costs the people who paste addresses by hand.
## The field that holds the address Every stored request in a **Postman collection** — the JSON document a collection is exported as — keeps its address in the `url` member of `request`. The **collection format** (the schema the file names in `info.schema`) accepts two entirely different shapes in that one place, and both are legal, even for neighbouring requests inside the same file. The first shape is a **flat string**: the whole address in a single value, exactly as somebody typed it. The second is an **object**, whose members break that same address into named parts: `raw`, `protocol`, `host`, `path`, `port`, `query`, `hash` and `variable`. Neither is a newer replacement for the other. The format simply permits both, which means any tool that reads a collection — a diff viewer, a code generator, a script that rewrites hosts before a run — must cope with a `url` that is a string and a `url` that is an object, and must not assume the file is uniform. ## What the object's parts carry | member | what it holds | |---|---| | `raw` | the whole address as one string, sitting beside the parts | | `protocol` | the scheme portion of the address | | `host` | the host portion | | `port` | the port, when the address carries one | | `path` | the path, as its segments | | `query` | the query entries, each an object with its own `key` and `value` | | `hash` | the fragment that follows the `#` | | `variable` | values for the path's colon-prefixed segments | Three of those repay a second look: - **`raw` is inside the object, not opposite it.** People often picture "raw form versus structured form" as two rival shapes; in fact the structured shape carries the whole address as `raw` as well, so a reader never loses the one-line view. - **`query` is a list of entries, not an encoded blob.** Each entry stands on its own and can carry `disabled`, which keeps the entry in the document while leaving it out of what is actually sent. - **`variable` pairs with `path`.** A segment written with a leading colon is a placeholder; the SDK's `getPath` reads those colon-prefixed segments when it renders the path. ## Why the split is worth having The practical difference is not how the request is sent — both shapes describe the same address — but what can be done to the document afterwards. 1. **Editing one part.** With the object form, changing the host, dropping a query entry or renaming a path segment is a change to one named member. With the flat string, every edit is a rewrite of the whole value, and any tool doing it must parse the address itself, correctly, including escaping. 2. **Reviewing a change.** In version control, the object form puts each query entry on its own line, so a review shows exactly which entry moved. The flat string collapses every possible edit into one changed line, and a reviewer has to spot the difference by eye inside a long address. 3. **Generating and rewriting.** Machine edits — swapping a host for a staging one, adding a parameter across many requests — are safe against named members and fragile against string surgery. That is the whole reason the format bothers with a structured alternative: a saved address is a document people and programs edit long after it was first typed, and only the broken-down form can be edited a piece at a time. ## Reading a file that mixes both Because both shapes are legal, defensive reading is the rule. A script that walks a collection and expects `url.query` will throw the moment it meets a request whose `url` is a plain string, and the failure will look like a missing field rather than a shape mismatch. Check the type first, and treat the string case as "parts not broken out" rather than as a broken file. When a request has an object `url`, prefer the named members over re-parsing `raw`; when it has a string, either parse it deliberately or leave it alone. ## Where this stops This is a question about **how an address is stored in a document**, not about how to design one. Which values belong in a path segment and which in the query string, how to keep a URI stable, and how a query grammar should look are API-design questions owned elsewhere. Likewise, brace-token expansion and which variable scope wins are separate subjects; the `variable` member here is the url object's own list for its colon-prefixed segments.
- A request stores its url as a flat string. What must a script do to change one query entry?Parse the address itself, edit the piece, and re-serialise the whole value back into the single field — including any escaping. There is no named member to address, so the edit is string surgery, and a mistake corrupts the rest of the address rather than one parameter.
- Where does raw sit relative to the broken-out parts, and what follows from that?`raw` is a member of the url object itself, alongside `protocol`, `host`, `path` and `query`. So the structured form still carries the whole address as one readable string, and a reader should not treat raw and structured as mutually exclusive shapes.
- What breaks in a tool that assumes every url in a collection is an object?It fails on any request saved with the flat string form, and the symptom is misleading: reading `url.query` on a string yields nothing, so the tool reports a request with no parameters instead of an unsupported shape. Check the type before reaching for members.
A flat string is an address scrawled on one line of an envelope; the object form is the same address typed into a form with a field per line, where you can correct the street without rewriting the country.
saying these in an interview costs you the question
- Claims the object form replaced the string form entirely
- Thinks raw lives outside the url object, as a rival shape
- Treats query as one encoded string rather than a list of entries
- Assumes every request in a file uses the same url shape
- Says a flat string can be edited part by part safely
- Confuses the url object's variable list with a global store