Schema Registry API リファレンス

Looking for Schema Management Confluent Cloud docs? You are currently viewing Confluent Platform documentation. If you are looking for Confluent Cloud docs, check out Schema Management on Confluent Cloud.

概要

このセクションは、Schema Registry API についての詳細なリファレンスとなっています。API のテストには、curl を使用することをお勧めします。curl を使用して API をテストする例については、「Schema Registry API の使用例」を参照してください。

Schema Registry のチュートリアル で使用されている curl API 呼び出しも参照してください。「フォーマット、シリアライザー、逆シリアライザー」の詳細セクションに記載された各種のスキーマフォーマットをお試しいただけます。

互換性

Schema Registry サーバーは、新しいスキーマがサブジェクトに登録される際に特定の互換性ルールを適用することができます。次の互換性タイプがあります。

  • BACKWARD: (デフォルト)新しいスキーマを使用するコンシューマーは、一番最後に登録されたスキーマを使用するプロデューサーからの出力データを読み取ることができます。
  • BACKWARD_TRANSITIVE: 新しいスキーマを使用するコンシューマーは、既に登録されている任意のスキーマを使用するプロデューサーからの出力データを読み取ることができます。
  • FORWARD: 一番最後に登録されたスキーマを使用するコンシューマーが、新しいスキーマを使用するプロデューサーからの出力データを読み取ることができます。
  • FORWARD_TRANSITIVE: 既に登録されている任意のスキーマを使用するコンシューマーが、新しいスキーマを使用するプロデューサーからの出力データを読み取ることができます。
  • FULL: 新しいスキーマには、一番最後に登録されたスキーマに対する前方互換性と後方互換性があります。
  • FULL_TRANSITIVE: 新しいスキーマには、既に登録されている任意のスキーマに対する前方互換性と後方互換性があります。
  • NONE: スキーマの互換性チェックを無効にします。

Hadoop にはすべてのデータを読み込ませるのが一般的であるため、デフォルトの後方互換性のままにすることをお勧めします。

スキーマ解決の詳細については、「スキーマ進化と互換性」を参照してください。

コンテンツタイプ

Schema Registry REST サーバーでは、データのシリアル化フォーマットや使用されている API のバージョンを示すコンテンツタイプが、リクエストと応答の両方に使用されます。現在、サポートされるシリアル化フォーマットは JSON のみで、API のバージョンも v1 しかありません。しかし、将来のバージョンとの互換性を確保するためには、推奨されるコンテンツタイプをリクエストに指定するとともに、応答のコンテンツタイプをチェックする必要があります。

コンテンツタイプに使用される推奨のフォーマットは application/vnd.schemaregistry.v1+jsonv1 は API のバージョン、json はシリアル化フォーマット)です。ただし、コンテンツタイプをもっとあいまいに指定することもできます。たとえば、使用すべき API バージョンを指定せずに「application/vnd.schemaregistry+json」(最新の安定版が使用されます)としたり、「application/json」や「application/octet-stream」のようにしたりすることができます。後者の 2 つは、あくまで互換性と使用の容易性を意図してサポートされています。

実際のリクエストでは、フォーマットとバージョンの情報を HTTP Accept ヘッダーで、できるだけ具体的に指定する必要があります。

Accept: application/vnd.schemaregistry.v1+json

サーバーでは、コンテンツネゴシエーションもサポートされるため、重み付けされた複数の優先度指定を含めることができます。:

Accept: application/vnd.schemaregistry.v1+json; q=0.9, application/json; q=0.5

たとえば、新しいバージョンの API が推奨されるものの、そのバージョンの API が利用できるかどうかが定かでない場合に活用できます。

エラー

すべての API エンドポイントでは、エラーを表す HTTP ステータス(400 番台または 500 番台のステータス)がリクエストから返された場合、標準のエラーメッセージフォーマットが使用されます。たとえば、リクエストエンティティの必須フィールドに漏れがあると、次のような応答が生成されることがあります。

HTTP/1.1 422 Unprocessable Entity
Content-Type: application/vnd.schemaregistry.v1+json

{
    "error_code": 422,
    "message": "schema may not be empty"
}

ステータスコードをチェックすることをお勧めしますが、DELETE API 以外であれば、API 呼び出しのレスポンスを解析し、error_code フィールドの存在をチェックすることによってエラーを検出してもかまいません。

リクエストのフォーマットと有効な JSON の例

以下の例のリクエストは、読みやすいように体裁が整えられています。そのため、複数行からなるリクエスト例には改行が含まれています。複数行の例をコピーアンドペーストして API をテストする場合は、無効な JSON に起因するエラーを防ぐため、改行を削除してから実行してください。

たとえば、このリクエストを直接コピーアンドペーストすると、読みやすくするための改行が含まれているためにエラーが発生します。

{
  "schema":
    "{
       \"type\": \"record\",
       \"name\": \"test\",
       \"fields\":
         [
           {
             \"type\": \"string\",
             \"name\": \"field1\"
           },
           {
             \"type\": \"int\",
             \"name\": \"field2\"
           }
         ]
     }"
}

同じリクエストから改行を削除した例を次に示します。これは、コピーアンドペーストしても適切に動作するはずです。

{"schema": "{ \"type\": \"record\", \"name\": \"test\", \"fields\": [ { \"type\": \"string\", \"name\": \"field1\" }, { \"type\": \"int\", \"name\": \"field2\" } ] }" }

Schemas

GET /schemas/ids/{int: id}

入力された ID で識別されるスキーマ文字列を取得します。

パラメーター:
  • id (int) -- グローバルに一意のスキーマ識別子
レスポンスの JSON オブジェクト:
 
  • schema (string) -- ID で識別されるスキーマ文字列
ステータスコード:
  • 404 Not Found --
    • エラーコード 40403 -- スキーマが見つかりません。
  • 500 Internal Server Error --
    • エラーコード 50001 -- バックエンドデータストアでエラーが発生しました。

リクエストの例:

GET /schemas/ids/1 HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "schema": "{\"type\": \"string\"}"
}
GET /schemas/types/

Schema Registry に登録されているスキーマタイプを取得します。

レスポンスの JSON オブジェクト:
 
  • schema (string) -- 現在、Schema Registry で利用できるスキーマタイプです。
ステータスコード:
  • 404 Not Found --
    • エラーコード 40403 -- スキーマが見つかりません。
  • 500 Internal Server Error --
    • エラーコード 50001 -- バックエンドデータストアでエラーが発生しました。

リクエストの例:

GET /schemas/types HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  ["JSON", "PROTOBUF", "AVRO"]
}
GET /schemas/ids/{int: id}/versions

入力された ID で識別されるサブジェクトとバージョンのペアを取得します。

パラメーター:
  • id (int) -- グローバルに一意のスキーマ識別子
応答(オブジェクトの JSON 配列):
 
  • subject (string) -- サブジェクトの名前
  • version (int) -- 返されたスキーマのバージョン
ステータスコード:
  • 404 Not Found --
    • エラーコード 40403 -- スキーマが見つかりません。
  • 500 Internal Server Error --
    • エラーコード 50001 -- バックエンドデータストアでエラーが発生しました。

リクエストの例:

GET /schemas/ids/1/versions HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

[{"subject":"test-subject1","version":1}]

Subjects

Schema Registry に登録されているすべてのサブジェクトのリストは、subjects リソースから得られます。サブジェクトとは、スキーマが登録される際の名前のことです。Kafka に Schema Registry を使用している場合、登録の対象がトピックのキースキーマであるか値スキーマであるかに応じて、"<topic>-key" または "<topic>-value" がサブジェクトとなります。

ちなみに

現在、特定の ID のサブジェクトを検索する組み込みのルックアップ API はありません。それに代わる 2 段階のプロセスについては、「特定の ID に関連付けられているすべてのサブジェクトを一覧表示する」を参照してください。

GET /subjects

登録されているサブジェクトのリストを取得します(「API の使用例」の「すべてのサブジェクトを一覧表示する」も参照してください)。

パラメーター:
  • subject (string) -- サブジェクトの名前
  • deleted (boolean) -- 現在のサブジェクトと論理的に削除されたサブジェクトの両方のリストを取得するには、このリクエストの末尾に ?deleted=true を追加します。デフォルト値は false です。このフラグが含まれていない場合は、現在のサブジェクトだけが取得されます(論理的に削除されたサブジェクトは含められません)。物理的な削除と論理的な削除については、後述の delete API の説明を参照してください。
応答(オブジェクトの JSON 配列):
 
  • name (string) -- サブジェクト
ステータスコード:
  • 500 Internal Server Error --
    • エラーコード 50001 -- バックエンドデータストアでエラーが発生しました。

リクエストの例:

GET /subjects HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

["subject1", "subject2"]
GET /subjects/(string: subject)/versions

指定したサブジェクトで登録されているバージョンのリストを取得します。

パラメーター:
  • subject (string) -- サブジェクトの名前
応答(オブジェクトの JSON 配列):
 
  • version (int) -- このサブジェクトで登録されているスキーマのバージョン
ステータスコード:
  • 404 Not Found --
    • エラーコード 40401 -- サブジェクトが見つかりません。
  • 500 Internal Server Error --
    • エラーコード 50001 -- バックエンドデータストアでエラーが発生しました。

リクエストの例:

GET /subjects/test/versions HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

[
  1, 2, 3, 4
]
DELETE /subjects/(string: subject)

指定されたサブジェクトとそれに関連付けられている互換性レベル(登録されている場合)を削除します。この API は、トピックをリサイクルする必要があるとき、または開発環境でのみ使用することをお勧めします。「スキーマ削除のガイドライン」も参照してください。

パラメーター:
  • subject (string) -- サブジェクトの名前
  • permanent (boolean) -- サブジェクトの物理的な削除を指定するには、このリクエストの最後に ?permanent=true を追加します。スキーマ ID を含め、関連するメタデータがすべて削除されます。デフォルト値は false です。このフラグを指定しなかった場合は、論理的な削除が実行されます。最初に論理的な削除を実行してから、物理的な削除を実行するようにしてください。このフラグは現在、レジストリでサポートされるスキーマのバージョン数に制限のある Confluent Cloud と Confluent Platform の両方でサポートされます。物理的な削除では、論理的な削除では行われないような方法で領域が解放されます。「スキーマ削除のガイドライン」の「スキーマの物理的な削除」および「Confluent Cloud の Schema Registry」も参照してください。
応答(オブジェクトの JSON 配列):
 
  • version (int) -- このサブジェクト名に基づいて削除されたスキーマのバージョン
ステータスコード:
  • 404 Not Found --
    • エラーコード 40401 -- サブジェクトが見つかりません。
  • 500 Internal Server Error --
    • エラーコード 50001 -- バックエンドデータストアでエラーが発生しました。

リクエストの例:

DELETE /subjects/test HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

[
  1, 2, 3, 4
]
GET /subjects/(string: subject)/versions/(versionId: version)

このサブジェクトで登録されているスキーマの特定のバージョンを取得します。

パラメーター:
  • subject (string) -- サブジェクトの名前
  • version (versionId) -- 取得するスキーマのバージョン。versionId には、[1,2^31-1] の範囲の値を指定できるほか、"latest" という文字列を指定できます。後者の場合は、指定されたサブジェクトで最後に登録されたスキーマが返されます。このリクエストが処理された直後にさらに新しいスキーマが登録される可能性について、注意してください。
レスポンスの JSON オブジェクト:
 
  • subject (string) -- このスキーマが登録されているサブジェクトの名前
  • id (int) -- グローバルに一意のスキーマ識別子
  • version (int) -- 返されたスキーマのバージョン
  • schemaType (string) -- スキーマフォーマット: AVRO(応答にスキーマタイプが表示されていない場合のデフォルトのタイプは AVRO)、PROTOBUF、JSONSCHEMA
  • schema (string) -- スキーマ文字列
ステータスコード:
  • 404 Not Found --
    • エラーコード 40401 -- サブジェクトが見つかりません。
    • エラーコード 40402 -- バージョンが見つかりません。
  • 422 Unprocessable Entity --
    • エラーコード 42202 -- バージョンが無効です。
  • 500 Internal Server Error --
    • エラーコード 50001 -- バックエンドデータストアでエラーが発生しました。

リクエストの例:

GET /subjects/test/versions/1 HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例(AVRO):

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "name": "test",
  "version": 1,
  "schema": "{\"type\": \"string\"}"
}

応答の例(PROTOBUF):

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "name": "test",
  "version": 1,
  "schemaType": "PROTOBUF"
  "schema": "{\"type\": \"string\"}"
}
GET /subjects/(string: subject)/versions/(versionId: version)/schema

このサブジェクトから、指定されたバージョンのスキーマを取得します。ただし、返されるスキーマはエスケープされていません。

パラメーター:
  • subject (string) -- サブジェクトの名前
  • version (versionId) -- 取得するスキーマのバージョン。versionId には、[1,2^31-1] の範囲の値を指定できるほか、"latest" という文字列を指定できます。後者の場合は、指定されたサブジェクトで最後に登録されたスキーマが返されます。このリクエストが処理された直後にさらに新しいスキーマが登録される可能性について、注意してください。
レスポンスの JSON オブジェクト:
 
  • schema (string) -- スキーマ文字列(非エスケープ)
ステータスコード:
  • 404 Not Found --
    • エラーコード 40401 -- サブジェクトが見つかりません。
    • エラーコード 40402 -- バージョンが見つかりません。
  • 422 Unprocessable Entity --
    • エラーコード 42202 -- バージョンが無効です。
  • 500 Internal Server Error --
    • エラーコード 50001 -- バックエンドデータストアでエラーが発生しました。

リクエストの例:

GET /subjects/test/versions/1/schema HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{"type": "string"}
POST /subjects/(string: subject)/versions

指定されたサブジェクトで新しいスキーマを登録します(実質的に新しいスキーマが作成されます)。正常に登録された場合、そのスキーマの、レジストリにおける一意の識別子が返されます。返された識別子は、このスキーマを schemas リソースから取得する際に必要となります。これは、サブジェクトに関連付けられているスキーマのバージョンとは異なります。同じスキーマを別のサブジェクトで登録しても、同じ識別子が返されます。一方、スキーマのバージョンは、別のサブジェクトにおいては異なる場合があります。

以前に登録されたスキーマが存在する場合、それらのスキーマとの間に、構成されたレベルに応じた互換性が備わっている必要があります。サブジェクトに構成されている互換性レベルは(設定されている場合)、GET http:get:: /config/(string: subject) を発行することで取得できます。そこでエラーが返された場合、"サブジェクト固有" の互換性レベルが、そのサブジェクトには設定されていないということになります。その場合は、GET http:get:: /config を使用して、"グローバル" な互換性レベルを特定してください。グローバルな互換性レベルは、すべてのサブジェクトに適用されます(サブジェクト固有の互換性が構成されている場合は、そちらの方がグローバルな互換性レベルよりも優先されます)。その例については、「サブジェクトの互換性の要件をアップデートする」および「サブジェクトの互換性の要件を取得する」を参照してください。

同じクラスターで Schema Registry のインスタンスが複数実行されているとき、スキーマ登録リクエストは、プライマリとして指定されているいずれかのインスタンスに転送されます。プライマリが利用できない場合、転送に失敗したことを示すエラーコードがクライアントに返されます。

schemaType が指定されていない場合は、AVRO が schemaType と見なされます。

パラメーター:
  • subject (string) -- スキーマが登録されるサブジェクト
リクエストの JSON オブジェクト:
 
  • schema -- スキーマ文字列
  • schemaType -- スキーマのフォーマットとして、AVRO(デフォルト)、PROTOBUF、JSON(省略可)を定義します。
  • references -- 参照先スキーマの名前を指定します(省略可)。詳細については、「スキーマ参照」を参照してください。
レスポンスの JSON オブジェクト:
 
  • id (int) -- グローバルに一意のスキーマ識別子
ステータスコード:
  • 409 Conflict -- スキーマに互換性がありません。
  • 422 Unprocessable Entity --
    • エラーコード 42201 -- スキーマが無効です。
  • 500 Internal Server Error --
    • エラーコード 50001 -- バックエンドデータストアでエラーが発生しました。
    • エラーコード 50002 -- 操作がタイムアウトしました。
    • エラーコード 50003 -- プライマリにリクエストを転送しているときにエラーが発生しました。

リクエストの例:

POST /subjects/test/versions HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

{
  "schema":
    "{
       \"type\": \"record\",
       \"name\": \"test\",
       \"fields\":
         [
           {
             \"type\": \"string\",
             \"name\": \"field1\"
           },
           {
             \"type\": \"com.acme.Referenced\",
             \"name\": \"int\"
           }
          ]
     }",
  "schemaType": "AVRO",
  "references": [
    {
       "name": "com.acme.Referenced",
       "subject":  "childSubject",
       "version": 1
    }
  ]
}

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{"id":1}
POST /subjects/(string: subject)

指定したサブジェクトで既にスキーマが登録されているかどうかをチェックします。既に登録されている場合、スキーマ文字列とそのグローバルに一意の識別子、このサブジェクトにおけるバージョン、サブジェクト名が返されます。

パラメーター:
  • subject (string) -- スキーマが登録されるサブジェクト
リクエストの JSON オブジェクト:
 
  • schema -- スキーマ文字列
  • schemaType -- スキーマのフォーマットとして、AVRO(デフォルト)、PROTOBUF、JSONSCHEMA(省略可)を定義します。
  • references -- 参照先スキーマの名前を指定します(省略可)。詳細については、「スキーマ参照」を参照してください。
レスポンスの JSON オブジェクト:
 
  • subject (string) -- このスキーマが登録されているサブジェクトの名前
  • id (int) -- グローバルに一意のスキーマ識別子
  • version (int) -- 返されたスキーマのバージョン
  • schema (string) -- スキーマ文字列
ステータスコード:
  • 404 Not Found --
    • エラーコード 40401 -- サブジェクトが見つかりません。
    • エラーコード 40403 -- スキーマが見つかりません。
  • 500 Internal Server Error -- 内部サーバーエラーが発生しました。

リクエストの例:

POST /subjects/test HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

{
      "schema":
         "{
                \"type\": \"record\",
                \"name\": \"test\",
                \"fields\":
                  [
                    {
                      \"type\": \"string\",
                      \"name\": \"field1\"
                    },
                    {
                      \"type\": \"int\",
                      \"name\": \"field2\"
                    }
                  ]
              }"
    }

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
      "subject": "test",
      "id": 1
      "version": 3
      "schema":
         "{
                \"type\": \"record\",
                \"name\": \"test\",
                \"fields\":
                  [
                    {
                      \"type\": \"string\",
                      \"name\": \"field1\"
                    },
                    {
                      \"type\": \"int\",
                      \"name\": \"field2\"
                    }
                  ]
              }"
    }
DELETE /subjects/(string: subject)/versions/(versionId: version)

このサブジェクトで登録されているスキーマの特定のバージョンを削除します。?permanent=true (後述)を使用して物理的な削除を実行した場合を除き、削除されるのは指定したバージョンだけです。スキーマ ID はそのまま残され、引き続きそのスキーマ ID を使用してデータをデコードすることができます。この API の使用は、どうしても必要な状況(過去に登録したスキーマを互換性上の理由から削除する必要がある、過去に登録したスキーマを再登録する必要があるなど)や開発環境に限定することをお勧めします。

パラメーター:
  • subject (string) -- サブジェクトの名前
  • version (versionId) -- 削除するスキーマのバージョン。versionId には、[1,2^31-1] の範囲の値を指定できるほか、"latest" という文字列を指定できます。後者の場合は、指定されたサブジェクトで最後に登録されたスキーマが削除されます。このリクエストが処理された直後にさらに新しいスキーマが登録される可能性について、注意してください。スキーマバージョンを物理的に削除する場合は、version:latest "ではなく" バージョン番号を入力として指定する必要があります。前者を指定すると、?permanent=true フラグを追加しても論理的な削除しか実行されません。「スキーマ削除のガイドライン」も参照してください。
  • permanent (boolean) -- サブジェクトの特定のバージョンを物理的に削除するよう指定するには、このリクエストの最後に ?permanent=true を追加します。スキーマ ID を含め、関連するメタデータがすべて削除されます。デフォルト値は false です。このフラグを指定しなかった場合は、論理的な削除が実行されます。最初に論理的な削除を実行してから、物理的な削除を実行するようにしてください。このフラグは現在、レジストリでサポートされるスキーマのバージョン数に制限のある Confluent Cloud と Confluent Platform の両方でサポートされます。物理的な削除では、論理的な削除では行われないような方法で領域が解放されます。「スキーマ削除のガイドライン」の「スキーマの物理的な削除」および「Confluent Cloud の Schema Registry」も参照してください。
レスポンスの JSON オブジェクト:
 
  • int -- 削除されたスキーマのバージョン
ステータスコード:
  • 404 Not Found --
    • エラーコード 40401 -- サブジェクトが見つかりません。
    • エラーコード 40402 -- バージョンが見つかりません。
  • 422 Unprocessable Entity --
    • エラーコード 42202 -- バージョンが無効です。
  • 500 Internal Server Error --
    • エラーコード 50001 -- バックエンドデータストアでエラーが発生しました。

リクエストの例:

DELETE /subjects/test/versions/1 HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

1
GET /subjects/(string: subject)/versions/{versionId: version}/referencedby

指定したサブジェクトとバージョンに該当するスキーマを参照しているスキーマの ID のリストを取得します。

パラメーター:
  • subject (string) -- サブジェクトの名前
  • version (versionId) -- 取得するスキーマのバージョン。versionId には、[1,2^31-1] の範囲の値を指定できるほか、"latest" という文字列を指定できます。後者の場合は、指定されたサブジェクトで最後に登録されたスキーマが返されます。このリクエストが処理された直後にさらに新しいスキーマが登録される可能性について、注意してください。
応答(オブジェクトの JSON 配列):
 
  • id (int) -- グローバルに一意のスキーマ識別子
ステータスコード:
  • 404 Not Found --
    • エラーコード 40401 -- サブジェクトが見つかりません。
  • 500 Internal Server Error --
    • エラーコード 50001 -- バックエンドデータストアでエラーが発生しました。

リクエストの例:

GET /subjects/test/versions/1/referencedby HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

[
  1, 2, 3, 4
]

Mode

モードを設定するには、mode リソースを使用します。モードは、Schema Registry に対してグローバルレベルで設定するか、特定のサブジェクトに対して設定することができます。使用できるモードは次のとおりです。

  • IMPORT
  • READONLY
  • READWRITE

ちなみに

Schema Registry クラスターのモード変更を有効にするには、さらに、Schema Registry のプロパティファイルで mode.mutability=true を設定してから、Schema Registry を起動する必要があります。このプロパティを設定する例および Schema Registry のモードをグローバルレベルで変更する例については、「スキーマの移行」の手順の中で紹介しています。

GET /mode

現在 Schema Registry にグローバルレベルで設定されているモードを取得します。

リクエストの JSON オブジェクト:
 
  • mode (string) -- Schema Registry のモード。IMPORT、READONLY、READWRITE(デフォルト)のいずれかになります。
ステータスコード:
  • 500 Internal Server Error --
    • エラーコード 50001 -- バックエンドデータストアでエラーが発生しました。

リクエストの例:

GET /mode HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "mode": "READWRITE"
}
PUT /mode

Schema Registry のグローバルなモードをアップデートします。Schema Registry のプロパティファイルに mode.mutability=true を設定して Schema Registry を起動した場合にのみ機能します。

リクエストの JSON オブジェクト:
 
  • mode (string) -- 新しいモード。IMPORT、READONLY、READWRITE のいずれかを指定する必要があります。
ステータスコード:
PUT /mode HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

{
  "mode": "IMPORT",
}

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "mode": "IMPORT",
}
GET /mode/(string: subject)

サブジェクトのモードを取得します。

パラメーター:
  • subject (string) -- サブジェクトの名前
リクエストの JSON オブジェクト:
 
  • mode (string) -- サブジェクトのモード。IMPORT、READONLY、READWRITE(デフォルト)のいずれかになります。
ステータスコード:
  • 404 Not Found -- サブジェクトが見つかりません。
  • 500 Internal Server Error --
    • エラーコード 50001 -- バックエンドデータストアでエラーが発生しました。

リクエストの例:

GET /mode/test HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
   "mode": "READWRITE"
}
PUT /mode/(string: subject)

指定されたサブジェクトのモードをアップデートします。Schema Registry のプロパティファイルに mode.mutability=true を設定して Schema Registry を起動した場合にのみ機能します。

パラメーター:
  • subject (string) -- サブジェクトの名前
リクエストの JSON オブジェクト:
 
  • mode (string) -- サブジェクトの新しいモード。IMPORT、READONLY、READWRITE(デフォルト)のいずれかを指定する必要があります。
ステータスコード:

リクエストの例:

PUT /mode/test HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

{
  "mode": "READONLY",
}

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "mode": "READONLY",
}

互換性

サブジェクトの特定のバージョンのスキーマに対するスキーマの互換性は、compatibility リソースを使用してテストできます。

POST /compatibility/subjects/(string: subject)/versions/(versionId: version)

サブジェクトの特定のバージョンのスキーマと比較して、入力されたスキーマの互換性をテストします。チェックで適用される互換性レベルは、サブジェクトに構成されている互換性レベル(http:get:: /config/(string: subject))になることに注意してください。そのサブジェクトの互換性レベルが変更されていない場合は、グローバルな互換性レベルが適用されます(http:get:: /config)。

パラメーター:
  • subject (string) -- 互換性テストの比較対象となるスキーマバージョンのサブジェクト。
  • version (versionId) -- 互換性テストの比較対象となるサブジェクトのスキーマバージョン。versionId には、[1,2^31-1] の範囲の値を指定できるほか、"latest" という文字列を指定できます。後者の場合は、指定されたサブジェクトで最後に登録されたスキーマとの間で、入力スキーマの互換性がチェックされます。
  • verbose (boolean) -- スキーマが互換性テストで不合格になった場合に、その理由を出力するには、このリクエストの末尾に ?verbose=true を追加します。デフォルトでは false です(スキーマが互換性テストで不合格になった理由は出力されません)。
リクエストの JSON オブジェクト:
 
  • schema -- スキーマ文字列
  • schemaType -- スキーマのフォーマットとして、AVRO(デフォルト)、PROTOBUF、JSONSCHEMA(省略可)を定義します。
  • references -- 参照先スキーマの名前を指定します(省略可)。詳細については、「スキーマ参照」を参照してください。
レスポンスの JSON オブジェクト:
 
  • is_compatible (boolean) -- 互換性がある場合は Trueです。それ以外の場合は False です。
ステータスコード:
  • 404 Not Found --
    • エラーコード 40401 -- サブジェクトが見つかりません。
    • エラーコード 40402 -- バージョンが見つかりません。
  • 422 Unprocessable Entity --
    • エラーコード 42201 -- スキーマが無効です。
    • エラーコード 42202 -- バージョンが無効です。
  • 500 Internal Server Error --
    • エラーコード 50001 -- バックエンドデータストアでエラーが発生しました。

リクエストの例:

POST /compatibility/subjects/test/versions/latest HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

{
  "schema":
    "{
       \"type\": \"record\",
       \"name\": \"test\",
       \"fields\":
         [
           {
             \"type\": \"string\",
             \"name\": \"field1\"
           },
           {
             \"type\": \"int\",
             \"name\": \"field2\"
           }
         ]
     }"
}

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "is_compatible": true
}

Config

クラスターレベルの構成値およびサブジェクトのオーバーライドは、config リソースで調査できます。

PUT /config

グローバルな互換性レベルをアップデートします。

同じクラスターで Schema Registry の複数のインスタンスが実行されているとき、アップデートリクエストは、プライマリとして指定されているいずれかのインスタンスに転送されます。プライマリが利用できない場合、転送に失敗したことを示すエラーコードがクライアントに返されます。

リクエストの JSON オブジェクト:
 
  • compatibility (string) -- 新しいグローバルな 互換性レベル。BACKWARD、BACKWARD_TRANSITIVE、FORWARD、FORWARD_TRANSITIVE、FULL、FULL_TRANSITIVE、NONE のいずれかを指定する必要があります。
ステータスコード:
  • 422 Unprocessable Entity --
    • エラーコード 42203 -- 互換性レベルが無効です。
  • 500 Internal Server Error --
    • エラーコード 50001 -- バックエンドデータストアでエラーが発生しました。
    • エラーコード 50003 -- プライマリにリクエストを転送しているときにエラーが発生しました。
PUT /config HTTP/1.1
Host: kafkaproxy.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

{
  "compatibility": "FULL"
}

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "compatibility": "FULL"
}
GET /config

グローバルな互換性レベルを取得します。

リクエストの JSON オブジェクト:
 
  • compatibility (string) -- グローバルな互換性レベル。BACKWARD、BACKWARD_TRANSITIVE、FORWARD、FORWARD_TRANSITIVE、FULL、FULL_TRANSITIVE、NONE のいずれかになります。
ステータスコード:
  • 500 Internal Server Error --
    • エラーコード 50001 -- バックエンドデータストアでエラーが発生しました。

リクエストの例:

GET /config HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "compatibilityLevel": "FULL"
}
PUT /config/(string: subject)

指定されたサブジェクトの互換性レベルをアップデートします。詳しい使用例については、「サブジェクトの互換性の要件をアップデートする」を参照してください。

パラメーター:
  • subject (string) -- サブジェクトの名前
リクエストの JSON オブジェクト:
 
  • compatibility (string) -- サブジェクトの新しい互換性レベル。BACKWARD、BACKWARD_TRANSITIVE、FORWARD、FORWARD_TRANSITIVE、FULL、FULL_TRANSITIVE、NONE のいずれかを指定する必要があります。
ステータスコード:
  • 422 Unprocessable Entity --
    • エラーコード 42203 -- 互換性レベルが無効です。
  • 500 Internal Server Error --
    • エラーコード 50001 -- バックエンドデータストアでエラーが発生しました。
    • エラーコード 50003 -- プライマリにリクエストを転送しているときにエラーが発生しました。

リクエストの例:

PUT /config/test HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

{
  "compatibility": "FULL"
}

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "compatibility": "FULL"
}
GET /config/(string: subject)

サブジェクトの互換性レベルを取得します。詳しい使用例については、「サブジェクトの互換性の要件を取得する」を参照してください。

パラメーター:
  • subject (string) -- サブジェクトの名前
  • defaultToGlobal (boolean) -- サブジェクトレベルで設定されている互換性(設定されている場合)を表示するには、このリクエストの最後に ?defaultToGlobal=false を追加します。互換性チェックに使用される要件を表示するには、?defaultToGlobal=true を追加します。例については、「サブジェクトに対して有効になっている互換性要件を表示する」を参照してください。
リクエストの JSON オブジェクト:
 
  • compatibility (string) -- サブジェクトの互換性レベル。BACKWARD、BACKWARD_TRANSITIVE、FORWARD、FORWARD_TRANSITIVE、FULL、FULL_TRANSITIVE、NONE のいずれかになります。
ステータスコード:
  • 404 Not Found -- サブジェクトが見つかりません。
  • 500 Internal Server Error --
    • エラーコード 50001 -- バックエンドデータストアでエラーが発生しました。

リクエストの例:

GET /config/test HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
   "compatibilityLevel": "FULL"
}

エクスポーター(プレビュー)

重要

このセクションのエクスポーター API は、Schema Linking をサポートします。Confluent Cloud では、現在のところ Schema Linking はプレビュー機能です。プレビュー機能とは、開発者から早い段階でフィードバックを受けるために提供しているコンポーネントのことです。この機能は、評価用、本稼働環境以外でのテスト用、あるいは Confluent にフィードバックを提供するために使用できます。これらの Schema Linking の API に関する質問やフィードバックについては、stream-governance-preview@confluent.io にメールでお問い合わせください。

Confluent Cloud での Schema Linking(プレビュー) をサポートするために、Confluent Cloud では、これらの API が既に提供されています。

Confluent Platform で Schema Linking を有効にするには、今後リリースされる 7.0 のプレビュー以降で、次の構成プロパティを設定してください。

resource.extension.class=io.confluent.schema.exporter.SchemaExporterResourceExtension
kafkastore.update.handlers=io.confluent.schema.exporter.storage.SchemaExporterUpdateHandler
password.encoder.secret=mysecret

また、10(デフォルトの最大数)を超えるエクスポーターを作成できるようにするには、次のように設定します。

exporter.max.exporters=1000

エクスポーターリソースを使用することで、スキーマエクスポーターのライフサイクルを操作したり情報を照会したりすることができます。

GET /exporters

作成済みのスキーマエクスポーターのリストを取得します。

応答(オブジェクトの JSON 配列):
 
  • name (string) -- エクスポーターの名前

リクエストの例:

GET /exporters HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

["exporter1", "exporter2"]
POST /exporters

新しいスキーマエクスポーターを作成します。リクエスト本文の属性は、config を除きすべて省略可能です。

リクエストの JSON オブジェクト:
 
  • name (string) -- エクスポーターの名前
  • contextType (string) -- エクスポーターのコンテキストタイプ。CUSTOM、NONE、AUTO(デフォルト)のいずれか
  • context (string) -- エクスポーターのコンテキスト(contextType = CUSTOM の場合)
  • subjects[i] (string) -- 各エクスポーターサブジェクトの名前
  • config (map) -- エクスポーターの構成を含むマップ
レスポンスの JSON オブジェクト:
 
  • name (string) -- エクスポーターの名前
ステータスコード:
  • 409 Conflict --
    • エラーコード 40950 -- エクスポーター名が欠落しているか無効です
    • エラーコード 40951 -- エクスポーターの構成が欠落しているか無効です
    • エラーコード 40952 -- エクスポーターのサブジェクトが無効です
    • エラーコード 40960 -- エクスポーターが既に存在します
    • エラーコード 40964 -- エクスポーターが多すぎます

リクエストの例:

POST /exporters HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

{
  "name": "test-exporter",
  "contextType": "CUSTOM",
  "context": "test-context",
  "subjects": ["foo"],
  "config": {
    "schema.registry.url": "<Physical SR Endpoint>",
    "basic.auth.credentials.source": "USER_INFO",
    "basic.auth.user.info": "<SR Credentials>"
  }
}

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "name": "test-exporter"
}
PUT /exporters/(string: name)

スキーマエクスポーターの情報または構成をアップデートします。リクエスト本文の属性はすべて省略可能です。

パラメーター:
  • name (string) -- エクスポーターの名前
リクエストの JSON オブジェクト:
 
  • contextType (string) -- エクスポーターのコンテキストタイプ。CUSTOM、NONE、AUTO のいずれか。省略可能
  • context (string) -- エクスポーターのコンテキスト(contextType = CUSTOM の場合)
  • subjects[i] (string) -- 各エクスポーターサブジェクトの名前
  • config (map) -- エクスポーターの構成を含むマップ
レスポンスの JSON オブジェクト:
 
  • name (string) -- エクスポーターの名前
ステータスコード:
  • 404 Not Found --
    • エラーコード 40450 -- エクスポーターが見つかりません
  • 409 Conflict --
    • エラーコード 40952 -- エクスポーターのサブジェクトが無効です
    • エラーコード 40963 -- エクスポーターが一時停止されていません

リクエストの例:

PUT /exporters/test-exporter HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

{
  "contextType": "CUSTOM",
  "context": "test-context"
}

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "name": "test-exporter"
}
PUT /exporters/(string: name)/config

スキーマエクスポーターの構成をアップデートします。

注釈

POST リクエストのようにペイロードは {"config": {}} で囲まれません。構成は直接指定されます。

パラメーター:
  • name (string) -- エクスポーターの名前
リクエストの JSON オブジェクト:
 
  • config (map) -- エクスポーターの構成を含むマップ
レスポンスの JSON オブジェクト:
 
  • name (string) -- エクスポーターの名前
ステータスコード:
  • 404 Not Found --
    • エラーコード 40450 -- エクスポーターが見つかりません
  • 409 Conflict --
    • エラーコード 40963 -- エクスポーターが一時停止されていません

リクエストの例:

PUT /exporters/test-exporter/config HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

{
  "schema.registry.url": "<Physical SR Endpoint>",
  "basic.auth.credentials.source": "USER_INFO",
  "basic.auth.user.info": "<SR Credentials>"
}

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "name": "test-exporter"
}
GET /exporters/(string: name)

スキーマエクスポーターの情報を取得します。

パラメーター:
  • name (string) -- エクスポーターの名前
レスポンスの JSON オブジェクト:
 
  • name (string) -- エクスポーターの名前
  • contextType (string) -- エクスポーターのコンテキストタイプ。CUSTOM、NONE、AUTO(デフォルト)のいずれか
  • context (string) -- エクスポーターのカスタマイズされたコンテキスト(contextType = CUSTOM の場合)。
  • subjects[i] (string) -- 各エクスポーターサブジェクトの名前
  • config (map) -- エクスポーターの構成を含むマップ
ステータスコード:
  • 404 Not Found --
    • エラーコード 40450 -- エクスポーターが見つかりません

リクエストの例:

GET /exporters/test-exporter HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "name": "test-exporter",
  "contextType": "CUSTOM",
  "context": "test-context",
  "subjects": ["foo"],
  "config": {
    "schema.registry.url": "<Physical SR Endpoint>",
    "basic.auth.credentials.source": "USER_INFO",
    "basic.auth.user.info": "[hidden]"
  }
}

注釈

応答の認証情報は、[hidden] に置き換えられます。つまり、どのユーザーも API を使用して認証情報を照会することはできません。

GET /exporters/(string: name)/status

スキーマエクスポーターのステータスを取得します。

パラメーター:
  • name (string) -- エクスポーターの名前
レスポンスの JSON オブジェクト:
 
  • name (string) -- エクスポーターの名前
  • state (string) -- エクスポーターのステート。STARTING、RUNNING、PAUSED のいずれか
  • offset (long) -- エクスポーターのオフセット
  • ts (long) -- エクスポーターのタイムスタンプ
  • trace (string) -- エクスポーターのエラートレース
ステータスコード:
  • 404 Not Found --
    • エラーコード 40450 -- エクスポーターが見つかりません

リクエストの例:

GET /exporters/test-exporter/status HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "name": "test-exporter",
  "state": "RUNNING",
  "offset": 100,
  "ts": 1631206325,
  "trace": ""
}
GET /exporters/(string: name)/config

スキーマエクスポーターの構成を取得します。

注釈

POST リクエストのように応答ペイロードは {"config": {}} で囲まれません。構成は直接指定されます。

パラメーター:
  • name (string) -- エクスポーターの名前
レスポンスの JSON オブジェクト:
 
  • config (map) -- エクスポーターの構成を含むマップ
ステータスコード:
  • 404 Not Found --
    • エラーコード 40450 -- エクスポーターが見つかりません

リクエストの例:

GET /exporters/test-exporter/config HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "schema.registry.url": "<Physical SR Endpoint>",
  "basic.auth.credentials.source": "USER_INFO",
  "basic.auth.user.info": "[hidden]"
}
PUT /exporters/(string: name)/pause

スキーマエクスポーターを一時停止します。

パラメーター:
  • name (string) -- エクスポーターの名前
レスポンスの JSON オブジェクト:
 
  • name (string) -- エクスポーターの名前
ステータスコード:
  • 404 Not Found --
    • エラーコード 40450 -- エクスポーターが見つかりません
  • 409 Conflict --
    • エラーコード 40962 -- エクスポーターは既に開始されています

リクエストの例:

PUT /exporters/test-exporter/pause HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "name": "test-exporter"
}
PUT /exporters/(string: name)/reset

スキーマエクスポーターをリセットします。

パラメーター:
  • name (string) -- エクスポーターの名前
レスポンスの JSON オブジェクト:
 
  • name (string) -- エクスポーターの名前
ステータスコード:
  • 404 Not Found --
    • エラーコード 40450 -- エクスポーターが見つかりません
  • 409 Conflict --
    • エラーコード 40963 -- エクスポーターが一時停止されていません

リクエストの例:

PUT /exporters/test-exporter/reset HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "name": "test-exporter"
}
PUT /exporters/(string: name)/resume

スキーマエクスポーターを再開します。

パラメーター:
  • name (string) -- エクスポーターの名前
レスポンスの JSON オブジェクト:
 
  • name (string) -- エクスポーターの名前
ステータスコード:
  • 404 Not Found --
    • エラーコード 40450 -- エクスポーターが見つかりません
  • 409 Conflict --
    • エラーコード 40961 -- エクスポーターは既に実行されています

リクエストの例:

PUT /exporters/test-exporter/resume HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 200 OK
Content-Type: application/vnd.schemaregistry.v1+json

{
  "name": "test-exporter"
}
DELETE /exporters/(string: name)

スキーマエクスポーターを削除します。

パラメーター:
  • name (string) -- エクスポーターの名前
ステータスコード:
  • 404 Not Found --
    • エラーコード 40450 -- エクスポーターが見つかりません

リクエストの例:

DELETE /exporters/test-exporter HTTP/1.1
Host: schemaregistry.example.com
Accept: application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json

応答の例 :

HTTP/1.1 204 No Content

Confluent Cloud の Schema Registry

スキーマ数の上限

Confluent Cloud の Schema Registry では、ベーシッククラスタースタンダードクラスター専用クラスター のレジストリでサポートされるスキーマバージョンの数に上限があります(「Confluent Cloud クラスターのタイプ」を参照)。使用状況および使用可能なスキーマは、Confluent Cloud Console で確認できます。「Confluent Cloud で使用できるスキーマ数の確認」を参照してください。

使用量が上限に達してレジストリがいっぱいになっているときに新しいスキーマの登録リクエストを実行すると、次の HTTP 応答が返されます。

HTTP/1.1 422 Unprocessable Entity
Content-Type: application/vnd.schemaregistry.v1+json

{
    "error_code": 403,
    "message": "Schema Limit Exceeded"
}

必要に応じて 新しいスキーマを登録できるようストレージ領域を解放する 方法については、以下のトピックを参照してください。

Confluent Cloud の機能について詳しくは、「Confluent Cloud のサポートされる機能」を参照してください。

新しいスキーマを登録できるようにレジストリのストレージ領域を解放する方法

単純にスキーマを削除しただけではレジストリの領域は解放されません。"論理的な削除" が実行されるだけで、スキーマ ID を再利用できないためです。スキーマのカウントでは ID が追跡されるので、新しいスキーマが追加されるにつれて使用数が増加します。スキーマが論理的に削除されたかどうかは考慮されません。

Confluent Cloud では、新たにスキーマの "物理的な削除" がサポートされています。2 段階の処理(論理的な削除の後に、物理的な削除を実行)によって実現され、2 回目の削除時にはクエリ文字列 ?permanent=true を使用することになります。Schema Registry が スキーマ数の上限 に達した場合は、新しいスキーマを追加できるよう領域を解放できます。「スキーマ削除のガイドライン」の「スキーマの物理的な削除」で説明されている手順に従ってください。