When people ask for an export, they usually mean “I can see this information on a screen, and I want it somewhere else.” That is a smaller request than “build an API”, and it’s worth keeping it that way.
For example, say a catalog application has a series overview page that shows a title, a publisher, the number of issues, and a date range. Someone wants that table in a spreadsheet so they copy and paste it, and it breaks whenever a cell contains a comma or a line break. The first useful step is to treat the screen as a list of records and decide what one record contains. In JSON, it might look like:
{
"name": "Example Series",
"publisher": "Example Press",
"issue_count": 12,
"first_year": 1987,
"last_year": null
}Even a small record forces decisions the screen was hiding. What does last_year mean for a series that is still running? On the page it might be blank or say “present”. In a file, null is clearer than an empty string or a made-up year, and it should be documented. The same goes for which series are included. If the screen hides some records, the export shouldn’t quietly include them, and if it does, that needs to be a decision rather than an accident.
The next question is how the data gets loaded. A screen can get away with fetching related data one row at a time because it only shows a page at a time; an export that walks every series may turn that habit into thousands of extra queries. Load the related data deliberately, in bulk, and measure it before you claim it’s fast. (I haven’t measured anything for this example, so I won’t.)
Then make the export easy to find. A link on the page where the data already lives (with a note saying what is and isn’t in the file) does more good than a well-designed endpoint nobody knows about.
Just as important is writing down what the export does not cover. Maybe creators or notes are a natural next request. Each of those has its own questions about inclusion and missing values, and none of them is answered by the first export. Saying “not yet” in the documentation is cheaper than promising a general interface and then maintaining it.
If a wider API is already being planned, the bounded export should fit alongside that work rather than compete with it. Tell the API designers what the export contains and expect to change or retire it if they later provide something better. Adjacent exports can wait for that conversation.
This is a pattern that fits a narrow, well-understood request, not a claim that exports are always better than an API. If many people need many different slices of the data, that’s the point to design the larger interface.
Start with one screen, one record, and one clearly documented file.
—jhunterj