beacon_operations.get_beacon_service_info
GET /service-info
Get information about the beacon using GA4GH ServiceInfo format
Responses
200
Successful operation
A way for a service to describe basic metadata concerning a service alongside a set of capabilities and/or limitations of the service. More information on GitHub.
object
URL of the contact for the provider of this service, e.g. a link to a contact form (RFC 3986 format), or an email (RFC 2368 format).
Timestamp describing when the service was first deployed and available (RFC 3339 format)
Description of the service. Should be human readable and provide information about the service.
URL of the documentation of this service (RFC 3986 format). This should help someone learn how to use your service, including any specifics required to access data, e.g. authentication.
Environment the service is running in. Use this to distinguish between production, development and testing/staging deployments. Suggested values are prod, test, dev, staging. However this is advised and not enforced.
Unique ID of this service. Reverse domain name notation is recommended, though not required. The identifier should attempt to be globally unique so it can be used in downstream aggregator services e.g. Service Registry.
Name of this service. Should be human readable.
Organization providing the service
object
Name of the organization responsible for the service
URL of the website of the organization (RFC 3986 format)
Type of a GA4GH service
object
Name of the API or GA4GH specification implemented. Official GA4GH types should be assigned as part of standards approval process. Custom artifacts are supported.
Namespace in reverse domain name format. Use org.ga4gh
for implementations compliant with official GA4GH specifications. For services with custom APIs not standardized by GA4GH, or implementations diverging from official GA4GH specifications, use a different namespace (e.g. your organization’s reverse domain name).
Version of the API or specification. GA4GH specifications use semantic versioning.
Timestamp describing when the service was last updated (RFC 3339 format)
Version of the service being described. Semantic versioning is recommended, but other identifiers, such as dates or commit hashes, are also allowed. The version should be changed whenever the service is updated.