Add new field resultsHandover to BeaconAlleleResponse

[sdelatorrep]

This field will be used for handovers regarding the query response, not the Beacon (beaconHandover) or the dataset(s) (datasetHandover).

[mbaudis]

@sdelatorrep @juhtornr As mentioned in the call, "results" is strange since the dataset responses/handovers are also results; there, the method name describes the scope...
Logically, one could useaggregateHandover, in contrast to the non-aggregate, dataset specific responses/handovers. Also, a Beacon response (i.e. the typical "exists") should be an aggregateResponse.

But I'm actually not sure about the need for a beaconHandover. I think information about the Beacon is served by beaconInfo; and currently a beaconResponse describes the aggregate result. Isn't it enough to have:

• BeaconInfo
  • information about the Beacon, general features, supported protocols, version
• BeaconResponse, BeaconHandover
  • aggregate responses, handovers (all matched rsids ...)
• DatasetResponse, DatasetHandover
  • dataset specific ... etc.

WDYT?

[sdelatorrep]

Hi @mbaudis, I'd keep the beaconHandover inside beaconAlleleResponse because it could be useful to provide some information (e.g. contact) without forcing the user to go (again) to the info endpoint to get it. It could be redundant in some cases but, IMO, it does not harm and provides flexibility to the implementer.

I agree that aggregateHandover sounds better than resultsHandover. Please, @jrambla, give your feedback regarding this.

[mbaudis]

@sdelatorrep @jrambla O.k., makes sense for that purpose (Beacon information). Then

Also, a Beacon response (i.e. the typical "exists") should be an aggregateResponse.

Do we want to implement this (& similar...)? One could still keep the legacy response, I guess, but have a clearer structure.