Add an “apiVersion” field to BeaconAlleleResponse

[mfiume]

Currently only at Beacon.

Users won’t need to explicitly call the / endpoint to know the API version of the Beacon they are using.

[mcupak]

-0

API version is a property of the beacon, i.e. it belongs under /. A beacon will never return different API versions for different variants/responses, so there shouldn't be a need to to have it in BeaconAlleleResponse. The query syntax/semantics might change between different versions of the API, so you could argue that the client should know the version of the API before it executes a query anyway.

EDIT: Changed -1 to -0.

[jrambla]

+1

It is a sanity check for an asynchronous, distributed system like the one we are building.
Responses must be auto-suficient in terms of metadata. Each caller could, thus, double check the context from the response itself .
Nothing is impeding the user to receive answers from different servers between "info" call and actual query response, or just having deployed a new version between calls.

[mcupak]

Accepted.

[mfiume]

Can we revisit this @jrambla? I agree that it makes parsing the result simpler but not sure how much more of an advantage it is over querying the info endpoint once, and remembering the version for every subsequent request. As written, this field is optional, and so the only way a client will be confident in the version is to encode a fallback to look at the info endpoint anyways.

[jrambla]

+1 v.0.4

[sdelatorrep]

Closing as it is already included in merged PR #92