datasetIds and/or other additional request parameters?

[mbaudis]

The only ones that we agreed on adding were the collection ones if we prefer:
biosamples?datasetIds=1,2,3
to

dataset/1/biosamples
dataset/2/biosamples
dataset/3/biosamples

Originally posted by @jrambla in ga4gh-beacon/beacon-v2-Models#112 (comment)

datasetIds needs to be defined as request parameter for most entry types.

[mbaudis]

See also the work done on ga4gh-beacon/beacon-v2-Models#117

This requires a new cycle of work in the unified repository.

[gsfk]

Reviving this issue since I was looking around for a way to specify a set of datasets in a query. This still exists in an example and in the docs, so it seems reasonable to add them to the spec.

[mbaudis]

@gsfk I'm all for it. AFAIK @jrambla has objections since it breaks the "let's everything be doable by REST paths" but then, so many things would be much easier - or enabled at all - by having datasetIds and cohortIds as query parameters, for all (data) entry types; the response structure exists anyway (beaconResultsetsResponse).

For us, for now I've gone the way of basically moving to beacon-per-dataset (though we have the working datasetIds parameter for multi-dataset queries, but each beacon has a default one).

Btw.: I even think the example linked above was by @jrambla? Not my example style...

[gsfk]

I like being able to resolve datasets by path, but there are two difficulties:

• this only lets me query one dataset at a time
• while the spec includes definitions for e.g. /datasets/{id}/individuals and /datasets/{id}/g_variants some seemingly obvious endpoints are missing:

/datasets/{id}/analyses
/datasets/{id}/runs

Not sure if these were deliberately excluded? I also presumably won't have definitions for more nested paths, eg:

/datasets/{id}/individuals/{id}/biosamples

... so I lose some functionality that I would otherwise have at the root level of the beacon.

[mbaudis]

@gsfk

1. There were some previous discussions and I was told that it is in principle possible to use an array as {id}; e.g. datasets/dataset1,dataset2/g_variants is a valid REST syntax and you're good using it in your implementations - though not all implementations would support it (bycon does support multiple id values in the path but not for datasets ATM)
2. I've brought up the "all entities as endpoints" (e.g. /datasets/{id}/analyses) before and probably did an issue or PR ... and had discussed it with @jrambla - AFAIK this is one of the things were we just have to redo it for a new attempt.
3. Yeah, I also proposed the /datasets/{id}/individuals/{id}/biosamples because this was a way I'd implemented it myself previously but I was dissuaded from it (and it really could to a bag of hurt adding this for future use - either adoption hell or implementation hell, or both, since we didn't do it from the start).