A REST API gives clients a direct interface to Schema Registry. Producers, consumers, build plugins, and command-line tools send requests while Schema Registry manages schemas outside the Kafka brokers. section 3.2.3
The useful mental model is a request path around a distributed service: every node can serve reads, while secondary nodes forward schema registration and update requests to the primary node. The primary persists changes to Kafka’s compacted schemas topic. section 3.2.3
Common REST API work with Schema Registry includes:
- Register a schema with a POST request addressed to a subject and version endpoint. section 3.2.5
- List registered subjects, retrieve all versions for a subject, and retrieve a specific or latest schema version. section 3.2.5
- Pipe schema content through jq, send requests with curl, and format JSON responses for inspection. section 3.2.4 section 3.2.5
Registering and checking an Avro schema
Prepare an Avro schema as JSON, POST it to `/subjects/avro-avengers-value/versions` with the Schema Registry content type, and inspect the returned identifier. A successful registration returns `{ "id": 1 }`. Then query `/subjects`, `/subjects/avro-avengers-value/versions`, or `/subjects/avro-avengers-value/versions/latest` to discover and inspect the registered schema.
Figure 3.4 Schema Registry is a distributed application where only the primary node communicates with Kafka.
Trace how the primary Schema Registry node communicates with Kafka while clients use the REST API. section 3.2.3
Figure 3.5 All Schema Registry nodes can serve read requests.
Compare the read path, where every Schema Registry node can serve client read requests. section 3.2.3
