You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would it make sense to have only one service-info endpoint that tells us which version of the API is available or is that out of scope for this standard?
The text was updated successfully, but these errors were encountered:
@denis-yuen That's a great question. The idea of supporting multiple versions of the same standard natively came up when we were designing this, but we weren't sure if anyone would actually use it, so we decided to defer this until we have real-life use cases, and treat different versions as separate services.
So for now, I'd recommend going with the one per version setup, since the metadata would likely differ (e.g. version, type/version, createdAt/updatedAt etc.). You could additionally set up a Service Registry to list these different versions for discovery purposes, but there's no functionality there to group them or say it's the same standard.
If this is a common scenario you've seen, we'd be happy to work with you on something better for a newer version of Service Info and/or Service Registry APIs.
Does service-info have any recommendations as to whether it should be implemented one per server or one per API version?
For example, dockstore.org implements https://dockstore.org/api/ga4gh/trs/v2/service-info
If theoretically we have https://dockstore.org/api/ga4gh/trs/v3/service-info and
https://dockstore.org/api/ga4gh/trs/v4/service-info going forward, we would have three service-info endpoints, once per version.
Would it make sense to have only one service-info endpoint that tells us which version of the API is available or is that out of scope for this standard?
The text was updated successfully, but these errors were encountered: