Closed jeffkinnison closed 3 years ago
My current design is /parallels/<uuid>/tsv/
(since I was intending to implement tab-delimited only for the moment). Additional endpoints could then be added once more file types are supported.
I think we're on the same page about behavior.
Implemented endpoint is /parallels/<uuid>/downloads/
. Only gzipped tab-delimited is currently supported, though the endpoint seems easily extendible for other formats.
The current implementation creates the gzipped tab-delimited file on the server at the time of the search.
In the future, it could be possible to support other formats by doing one of the following:
I propose the following endpoint for search download:
/parallels/<search-id>.<filetype>
This should behave as follows:
GET
<search-id>
and<filetype>
are both valid, return a 200 with the results in the requested format<search-id>
or<filetype>
is invalid, return a 404 with an appropriate messageRationale
Even though we are possibly dynamically generating the files, conceptually the formatted version is always found in the same place by referencing the search and a particular file format. This should reduce the complexity of requests by removing the need for encoding URL params. Moreover, we should be able to separate out the download endpoint from the standard
/parallels/<search-id>/
by with something like@app.route('/parallels/<path:filename>')
and then useos.path.splitext
to separate the search id and filetype.