Supported Service Registry content and rules

Guide
  • Red Hat OpenShift Service Registry 1
  • Updated 18 October 2021
  • Published 24 September 2021

Supported Service Registry content and rules

Guide
Red Hat OpenShift Service Registry 1
  • Updated 18 October 2021
  • Published 24 September 2021

Red Hat OpenShift Service Registry is currently available for Development Preview. Development Preview releases provide early access to a limited set of features that might not be fully tested and that might change in the final GA version. Users are discouraged from using Development Preview software in production or for business-critical workloads. Limited documentation is available for Development Preview releases and is typically focused on fundamental user goals.

This document provides reference details on the supported artifact types, states, metadata, and content rules stored in Service Registry.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code and documentation. We are beginning with these four terms: master, slave, blacklist, and whitelist. Due to the enormity of this endeavor, these changes will be gradually implemented over upcoming releases. For more details on making our language more inclusive, see our CTO Chris Wright’s message.

Service Registry artifact types

You can store and manage a wide range of schema and API artifact types in Service Registry.

Table 1. Service Registry artifact types
Type Description

ASYNCAPI

AsyncAPI specification

AVRO

Apache Avro schema

GRAPHQL

GraphQL schema

JSON

JSON Schema

KCONNECT

Apache Kafka Connect schema

OPENAPI

OpenAPI specification

PROTOBUF

Google protocol buffers schema

WSDL

Web Services Definition Language

XSD

XML Schema Definition

Service Registry artifact states

The valid artifact states in Service Registry are ENABLED, DISABLED, and DEPRECATED.

Table 2. Service Registry artifact states
State Description

ENABLED

Basic state, all the operations are available.

DISABLED

The artifact and its metadata is viewable and searchable using the Service Registry web console, but its content cannot be fetched by any client.

DEPRECATED

The artifact is fully usable but a header is added to the REST API response whenever the artifact content is fetched. The Service Registry Rest Client will also log a warning whenever it sees deprecated content.

Service Registry artifact metadata

When an artifact is added to Service Registry, a set of metadata properties is stored along with the artifact content. This metadata consists of a set of generated read-only properties, along with some properties that you can set.

Table 3. Service Registry metadata properties
Property Type Editable

id

string

false

type

ArtifactType

false

state

ArtifactState

true

version

integer

false

createdBy

string

false

createdOn

date

false

modifiedBy

string

false

modifiedOn

date

false

name

string

true

description

string

true

labels

array of string

true

properties

map

true

Updating artifact metadata
  • You can use the Service Registry REST API to update the set of editable properties using the metadata endpoints.

  • You can edit the state property only by using the state transition API. For example, you can mark an artifact as deprecated or disabled.

Additional resources

For more details, see the /artifacts/{artifactId}/meta sections in the Apicurio Registry REST API documentation.

Service Registry content rule types

You can specify VALIDITY and COMPATIBILITY rule types to govern content evolution in Service Registry.

Table 4. Service Registry content rule types
Type Description

VALIDITY

Validate data before adding it to the registry. The possible configuration values for this rule are:

  • FULL: The validation is both syntax and semantic.

  • SYNTAX_ONLY: The validation is syntax only.

COMPATIBILITY

Ensure that newly added artifacts are compatible with previously added versions. The possible configuration values for this rule are:

  • FULL: The new artifact is forward and backward compatible with the most recently added artifact.

  • FULL_TRANSITIVE: The new artifact is forward and backward compatible with all previously added artifacts.

  • BACKWARD: Clients using the new artifact can read data written using the most recently added artifact.

  • BACKWARD_TRANSITIVE: Clients using the new artifact can read data written using all previously added artifacts.

  • FORWARD: Clients using the most recently added artifact can read data written using the new artifact.

  • FORWARD_TRANSITIVE: Clients using all previously added artifacts can read data written using the new artifact.

  • NONE: All backward and forward compatibility checks are disabled.

Service Registry content rule maturity

Not all content rules are fully implemented for every artifact type supported by Service Registry. The following table shows the current maturity level for each rule and artifact type:

Table 5. Service Registry content rule maturity matrix
Artifact type Validity rule Compatibility rule

Avro

Full

Full

Protobuf

Full

None

JSON Schema

Full

Full

OpenAPI

Full

None

AsyncAPI

Syntax Only

None

GraphQL

Syntax Only

None

Kafka Connect

Syntax Only

None

WSDL

Syntax Only

None

XSD

Syntax Only

None