Update the service-info to use the ga4gh discovery standard in progress (resolves #264) #277
Conversation
Removed the following: -title -contact -license Otherwise the [service-info endpoint proposal](https://github.com/ga4gh-discovery/ga4gh-service-info/blob/develop/service-info.yaml) is almost identical to what we had already.
briandoconnor
changed the title
rishidev
changed the title
| type: object | ||
| description: License information for the exposed API | ||
| description: Description of the service. | ||
| documentationUrl: |
There was a problem hiding this comment.
I feel it might be worth adding an explicit schemaURL to allow machine code to detect the OpenAPI/Swagger schema used by the service and self-configure. This could point to the GA4GH spec YAML or a local copy that may provide non-breaking extensions.
schemaUrl:
type: string
description: URL of the schema of this service (RFC 3986 format).There was a problem hiding this comment.
I like it, but I think that should be done GA4GH-wide, and we should be consistent -- maybe open an issue in https://github.com/ga4gh-discovery/ga4gh-service-info? (Not sure how they're handling enhancement requests there.)
There was a problem hiding this comment.
PR ga4gh-discovery/ga4gh-service-info#27 added.
There was a problem hiding this comment.
Yep, that's right @dglazer, any changes folks want for this should go to https://github.com/ga4gh-discovery/ga4gh-service-info
I'll make my best attempt to keep these in sync but I suspect the powers that be will allow us to bring in last minute changes to /service-info when that finalizes and before we cut an official 1.0 on our APIs.
See the issue #264
This PR is trying to harmonize the service-info endpoint to service-info format being proposed for all of GA4GH. This is still a work in progress and hasn't been approved yet.
Some potential problems, I think we ultimately need a service-info endpoint of service-info endpoints. Something like:
https://drs-server.com/service-info
And that should respond with something like:
In this way you could discover very clearly what are the available versions of DRS on this server and how to make requests for them.
Another point, right now there is no concept of API type. This could (should) be a CV term where we uniquely identify the API supported by this endpoint e.g. [wes, trs, drs, tes, etc]
Compared to our original service-info endpoint, I removed the following:
-title
-contact
-license
Otherwise the service-info endpoint proposal is almost identical to what we had already.