The three API endpoints that, according to the spec, should optionally return a CSV version, are:
(If there are more, let's identify them below)
As mentioned in the call, these responses return nested lists of things (so an organization will have many aliases, areas, sites, etc) and it's not obvious how we should serialize that into a tabular format. It seems like there are a few different approaches to this:
- Come up with some kind of delimiter When we stick the list of values into one column in the CSV, we could just put a semicolon (";") or a pipe ("|") or something in between each of the values and it'd be up to the person who downloads the CSV to unpack that. This might work for things like lists of roles and ranks for people but it'd be a bit clunky for something more complicated like lists of sources.
- Create a new row in the output for each variant This is probably the cleanest and easiest thing to do (since ultimately that's kinda how the database works) but it's not super user friendly.
- Create multiple CSV files Instead of packing all of the data into a single file, we could create a relational database of sorts and, when a user downloads a CSV of the dossier for an organization, what they'd get is one main file that has all of the simple attributes in it and then several other files that had things like sources for the different attributes and lists of more complex things. This also seems pretty easy to implement but might not be super easy for users to unravel.
- Some combination of the above Sticking former commanders of an organization in a separate CSV might be sane but sticking the
other_names
for each of those in a separate file seems slightly insane. What might make more sense is to use a delimiter for each of the other names.
Any other ideas as to how we might tackle this? @tonysecurityforcemonitor Do you have any use cases in mind that might inform this?