Closed ammatsun closed 9 years ago
Given that direct CSV/TSV production (not in a DwC-A) is likely on the list of features to be implemented in the next version of the download system, and the experience of that will likely be more understandable to users, is this really even something we'd want to implement in the search api?
I just feel like producing CSV dynamically in-API is something of an anti-pattern for an API, unless it is coupled with other significant features (like server side streaming responses, or range based paging). Even then, my experience would probably indicate that the types of clients that would only be able to process CSV would also be expecting only a very limited file download like response, not an actual API that they could interact with, steering even more towards something like the download API.
If you can find an example of an API client that is really expecting a CSV-only based API client, I might change my mind on this. For the examples listed though, it seems like they probably support GeoJSON (ArcGIS, QGIS) from the mapping endpoints, or just normal JSON (OpenRefine).
The iDigBio search APIs currently return responses only in JSON format.
This is a request for the same output to be returned in CSV format (comma, space or tab-separated values).
Suggestion to add two additional parameters to the API:
The use case for this is direct use by tools that can process CSV over HTTP requests (e.g., ArcGIS, QGIS, OpenRefine).