This version is still in development and is not considered stable yet. For the latest stable version, please use Korvet 0.19!

Schema Registry

Korvet exposes a Confluent Schema Registry-compatible REST API on the existing Spring Boot HTTP port when korvet.schema-registry.enabled=true. Kafka clients should configure schema.registry.url to the Korvet HTTP base URL and continue using Confluent serializers and deserializers.

When korvet.admin.security-enabled=true (the default), these endpoints require the same admin session cookie as the REST API — the web UI’s schema flows authenticate automatically, while headless registry clients need the cookie or a deployment with korvet.admin.security-enabled=false.

The registry supports registering and looking up Avro, Protobuf, and JSON Schema subjects, managing global and subject compatibility levels, and checking compatibility for new schemas. The Kafka broker preserves Confluent-encoded key and value bytes unchanged. When korvet.schema-registry.validate-produce=true, Korvet validates produced records that belong to registered <topic>-key or <topic>-value subjects and stores schema identity metadata alongside the archived payload.

korvet:
  schema-registry:
    enabled: true
    default-compatibility: BACKWARD
    validate-produce: true

Supported v1 endpoints include:

  • GET /subjects

  • GET /subjects/{subject}/versions

  • GET /subjects/{subject}/versions/{version}

  • GET /schemas/ids/{id}

  • POST /subjects/{subject}/versions

  • POST /subjects/{subject}

  • POST /compatibility/subjects/{subject}/versions/{version}

  • GET /config, PUT /config

  • GET /config/{subject}, PUT /config/{subject}

  • DELETE /subjects/{subject}

  • DELETE /subjects/{subject}/versions/{version} (latest supported)

Modes, exporters, contexts, and ACLs are intentionally out of scope for the first implementation.

Delete semantics

Deletes are Confluent-compatible in shape (a subject delete returns the deleted version numbers, a version delete returns the version number, and the error codes match: 40401 subject not found, 40402 version not found, 42202 invalid version) with the following documented deviations:

  • Every delete is a single-step permanent delete. Korvet has no soft-deleted state, so the Confluent two-phase soft-then-?permanent=true flow does not apply; the permanent parameter is accepted and ignored, and there is no ?deleted=true view.

  • Stored schemas and their global ids are always retained, so GET /schemas/ids/{id} keeps resolving after a delete and schema ids are never reused. Version numbers, however, follow permanent-delete rules: a re-created subject starts over at version 1, and re-registering after deleting the latest version reuses its number.

  • Korvet adds a guard Confluent does not have: deleting a subject whose topic-name-strategy topic ({topic}-key / {topic}-value) still exists is refused with 409/40901. The same guard applies to deleting the last remaining version of such a subject (which removes the subject itself). Delete the topic first, or force the delete with ?force=true on either endpoint.

  • Deleting the last remaining version of a subject removes the subject itself — no versionless subject lingers in GET /subjects.

Deleting every version of a {topic}-value subject disables produce validation for that topic (there is no schema left to validate against) — this is the main reason for the bound-topic guard.

Deletes require the ADMIN role; VIEWER sessions are read-only.