bulk data via the API

Context

I am interested in downloading the computed files for a large number of experiments, filtered by some conditions. I'm starting this process by hitting the search endpoint to obtain the experiment list.

Problem or idea

What I would like, ideally, is to be able to map directly from the computed files back to experiments and get the list of computed files by experiment code. Currently, I have to map each experiment to a list of samples and use that list of samples to then get the computed files, resulting in a lot of additional API calls. Since I know this project uses Django, I tried the usual Django query syntax of passing double-underscore queries to try and work my way back to the experiments but those "fail" silently, i.e. they are just ignored or return the entire result set. When I looked at the code, it turned out that certain bulk queries are possible, e.g. you can get a result set for all the samples for which you have an accession code, but unfortunately the search endpoint does not return any information about samples, so you still have to query experiments for sample details. To turn this into a bullet list of issues:

• There is no consistent way to work back from child to parent objects because custom code intercepts and handles the request that builds the queryset.
• Invalid parameters appear to be ignored entirely, leading to confusion about whether your filter is doing anything at all, example.
• Valid Django-style requests with double underscores are ignored when they do not match the custom request logic.
• The actual custom request logic is not documented anywhere. I had to read the code to find out that e.g. experiment_accession_code is a valid parameter to the samples endpoint.

Solution or next step

My suggestions are:

• Allow valid Django-type queries to be processed; I think anyone familiar with the framework would expect something like samples/?experiments=id to filter down to samples for that experiment rather than returning everything.
• Conversely, raise an error when invalid parameters are supplied. Otherwise it appears to the user that their incorrect filter has had an effect when really it's just returning everything.
• Make it possible to chain back from parents to children so that one can get e.g. all the computed files by experiment.
• (optionally?) Include additional child-related information in the search results, so that searching for experiments brings up e.g. a list of all sample accession codes associated with this experiment, obviating the need for multiple queries.
• Document the presently hidden query parameters in the API docs.
• Not strictly necessary and some people don't like this, but I have found that for complex endpoints like search it can be very beneficial to support a POST method so you can send a JSON blob specifying exactly what you want without worrying about exceeding GET URL limits. This is especially nice when you're trying to query inclusion using __in, which is nasty to do in GET params. Some people feel like this is a bad pattern but I've found that breaking that rule in isolated cases can provide big benefits.

I realize that this is a pretty big laundry list of various issues which are loosely related to each other and may not be of the highest priority. I'm happy to work on some or all of these, since I anticipate being a heavy user of Refine.Bio and I have close to a decade of experience with Django. There's no information about contributing to the project but I would assume a PR with the appropriate tests passing would to the trick.

Start at the search and samples API endpoints and trace the custom request logic that builds their querysets. Decide which part of the proposed API behavior is in scope, then define completion with tests for valid child-to-parent filters, invalid-parameter errors, and documentation of supported query parameters.