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.

Validation behavior

Produce-path schema validation is subject-scoped: validation is applied only when the topic component ({topic}-value or {topic}-key) has a registered Schema Registry subject.

  • No subject registered: Any binary payload is accepted, including data that starts with the Confluent wire-format magic byte 0x00 (e.g., zero-filled buffers or arbitrary binary data).

  • Subject registered: Strict wire-format validation applies — payloads must contain a valid Confluent Schema Registry wire header (magic byte + schema ID), and the referenced schema must exist and validate against the payload.

This behavior allows topics without schema requirements to accept arbitrary binary data (such as healthcheck payloads or raw binary streams) while enforcing strict schema validation on topics with registered subjects.

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.