Type: object
Description: 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.

Properties

contactUrl

• type: string (uri)

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).

contactUrl Value Example

"mailto:[email protected]"

createdAt

• type: string (date-time)

Timestamp describing when the service was first deployed and available (RFC 3339 format)

createdAt Value Example

"2019-06-04T12:58:19Z"

description

• type: string

Description of the service. Should be human readable and provide information about the service.

description Value Example

"This service provides..."

documentationUrl

• type: string (uri)

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.

documentationUrl Value Example

"https://docs.myservice.example.com"

environment

• type: string

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.

environment Value Example

"test"

id

• type: string

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.

id Value Example

"org.ga4gh.myservice"

name

• type: string

Name of this service. Should be human readable.

name Value Example

"My project"

organization

• type: object

Organization providing the service

type

• type: #/definitions/ServiceType

updatedAt

• type: string (date-time)

Timestamp describing when the service was last updated (RFC 3339 format)

updatedAt Value Example

"2019-06-04T12:58:19Z"

version

• type: string

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.

version Value Example

"1.0.0"