Beacon Schema version should be defined in the HTTP Header

[redmitry]

Hello,

Currently requested Schema Version is defined in the "meta" block of the request:

  "meta": {
    "requestedSchemas": {
      "Variant": "ga4gh-variant-representation-v0.1",
      "VariantAnnotation": "beacon-variant-annotation-v0.1",
      "Individual": "ga4gh-phenopacket-individual-v0.1",
      "Biosample": "ga4gh-schemablocks-biosample-v0.1"
    }
  },

This approach introduces implementation complexities. For instance, decision on parsing and validating must be implemented by the implementation code, instead of a REST framework (i.e. JAX-RS). Support for different formats by the same endpoint is usually implemented via HTTP “Accept” header. For instance, this approach is adopted by the GA4GH RNAGet API:

`application/vnd.ga4gh.rnaget.v1.0.0+json`

Kind regards,

Dmitry

[jrambla]

IMU, both approaches doesn't need to be alternative, right? I like the API to be explicit both in requests and in responses. This shouldn't preclude that the (suggested) implementation is purely relaying in such "explicitness", in a similar way that we are doing with user credentials (that are conveyed inside a token). I see a difference between transversal concerns (AuthN/AuthZ) and core features. Having said that is my "preference/principal", questions:

1. Would the "Accept" support such dynamic schema where different parts should honor different schemas?
2. Who is resolving the schema in the "Accept"?

[redmitry]

1. Would the "Accept" support such dynamic schema where different parts should honor different schemas?
2. Who is resolving the schema in the "Accept"?

This is a job of the REST framework to resolve. In java (JAX-RS) one may have several methods sharing the same @Path an with only difference on accept or content-type headers. For instance the same endpoint may serve json, yaml, xml, rdf, etc. providing four different implementations and it's a JAX-RS which choose them on the @Produces annotation.

[sdelatorrep]

@jrambla, @redmitry, I think we can close this issue, can't we?

[jrambla]

In the future, we need a better discussion on how much the tooling/frameworks should be leveraged against the verbosity of the API. Or how much the API should be linked to an specific protocol (e.g. HTTP) or be more agnostic to it. Etc. I believe that is not for version 2 but for a future one. GA4GH TASC future guidelines would also contribute to the discussion.