In an older-generation Postman collection export, how were the requests and their display sequence stored?
answer
- Content and arrangement were separate structures
- One array held every request
- Sequence was written as identifiers
- order for requests, folders_order for folders
basics
~20 sAn older export kept every request in one flat list and expressed sequence in sibling arrays of identifiers: order for the requests, and folders_order for the folders. Sequence was data alongside the content, not position within it.
solid answer
~50 sThe older generation wrote a **flat request list** — all requests in a single array with no nesting — and then expressed arrangement separately, in **`order`** and **`folders_order`** arrays holding identifiers. `order` gave the sequence of requests; `folders_order` gave the sequence of folders. Because a flat array cannot say which request sits inside which folder, or which comes first, that information had to live somewhere else, and it lived in those sibling arrays. The consequence is the interesting part: content and arrangement are two structures that can disagree. An identifier can appear in an `order` array with no matching request, or a request can exist that no ordering array mentions. The current format removes that class of problem by making sequence a property of the structure itself rather than a second list — that nested arrangement is its own subject.
code
json · 14 lines{
"requests": [
{
"id": "a1",
"name": "Create invoice",
"method": "POST",
"preRequestScript": "var started = Date.now();",
"tests": "var passed = true;"
}
],
"order": ["a1"],
"folders": [],
"folders_order": []
}go deeper
Recall the headline: an older export kept all requests in one flat list and wrote the sequence separately, in arrays named order and folders_order. That pairing is the recognisable fingerprint of the older shape.
Explain the mechanics — the ordering arrays hold identifiers, not requests, so arrangement is a second structure laid over a flat pool of content, and the two must be kept in agreement.
Demonstrate the failure reasoning: name the states the old shape can represent and the new one cannot, and argue for converting rather than hand-editing an inherited file.
Own the general principle — prefer document shapes where invalid states are unrepresentable, and weigh the expressiveness lost when sequence stops being independently addressable data.
## Two structures instead of one An older-generation collection export stored its content and its arrangement in **separate places**. The content was a **flat request list**: one array holding every request in the collection, with no nesting whatsoever. Arrangement was then supplied alongside it by two further arrays of identifiers — **`order`** and **`folders_order`** — plus a `folders` list describing the folders themselves. That division is the whole shape of the older generation, and every consequence follows from it. Read that way, the design is easy to reconstruct from first principles: if requests do not nest, then nothing about the array itself can express *which* folder a request belongs to or *what comes first*, so that information has to be written down somewhere else. The older generation wrote it down as data. ## What each array carried - **The flat request list** held the requests themselves — the actual method, URL, headers and body of each call, each carrying an identifier so it could be referred to from elsewhere. - **`order`** listed request identifiers in the sequence they should appear. It answers "what comes first", not "what exists". - **`folders_order`** listed folder identifiers in the sequence the folders should appear, which is the same trick applied one level up. - **The folders** described grouping, so a folder knew which requests it claimed rather than a request knowing its parent. Notice that none of these arrays holds a request. They hold **references**. The document's arrangement is therefore a graph of identifiers laid over a flat pool of content. ## Data-as-sequence versus position-as-sequence | Question | Older generation | Current generation | |---|---|---| | Where do requests live? | one flat list | nested entries | | Where does sequence live? | `order` / `folders_order` arrays | the position of an entry | | Can the two disagree? | yes — they are separate structures | no — there is only one structure | | What identifies a request to the sequence? | its identifier | nothing; it *is* in place | The right way to describe the difference is not "old is worse" but **"sequence used to be data, and is now position"**. A separate array of identifiers is more expressive in principle — you could reorder without touching content — and strictly more fragile in practice, because two structures that must agree eventually will not. ## Where the two structures can disagree Because arrangement is a second list, the older shape can represent states that are simply unrepresentable once sequence becomes position: 1. **A dangling reference** — an identifier appears in an ordering array, but no request in the flat list carries it. 2. **An unplaced request** — a request exists in the flat list, but no ordering array mentions it, so nothing says where it goes. 3. **A duplicate placement** — the same identifier appears more than once in an ordering array. 4. **Disagreeing levels** — the folder sequence and the request sequence tell different stories about the same content. None of these can occur in a structure where an entry's position *is* its order, because there is no second place for the answer to live. That is the argument to make in an interview: you are not comparing aesthetics, you are comparing how many states each shape can represent. ## Reading an old file today The practical advice follows directly: - **Identify the generation before parsing.** The file declares it in `info.schema`, and a flat list with `order` and `folders_order` beside it is the older shape. - **Do not hand-edit the arrangement.** Editing two structures that must agree, by hand, is how the disagreements above get introduced. - **Convert instead.** The collection transformer's `converter-v1-to-v2.js` exists precisely because this is a mechanical translation, not a judgement call. - **Review the result as a diff**, so that a request the old ordering arrays never mentioned is noticed by a person rather than silently landing somewhere. The current format's nested arrangement — what makes an entry a folder, and how position carries order — is a separate subject with its own rules. What this material owns is the shape that came before it and why the change was made.
- What can go wrong when the flat list and the ordering arrays disagree?The document becomes ambiguous. An identifier in an ordering array with no matching request is a dangling reference, and a request no ordering array mentions has no defined place. Neither state is representable once position carries the sequence, which is why hand-editing an older file is risky and converting it is not.
- Why did the format stop expressing sequence as a separate array?Because two structures that must agree eventually stop agreeing. Making an entry's position its order collapses content and arrangement into one structure, so dangling references, unplaced requests and duplicate placements simply cannot be written down. It trades a little expressiveness for a much smaller space of invalid documents.
Think of a deck of loose cards plus a written list of card numbers saying what order to read them in: lose or mistype one number and the deck is still complete but unreadable.
saying these in an interview costs you the question
- Says the older generation nested requests inside folders
- Claims order held numeric indexes into the request array
- Thinks folders_order sequenced requests within a folder
- Assumes content and arrangement could never disagree
- Proposes hand-editing both arrays to reorder a request