Looks up optional Schema-Reference header that is suppose to contain referenced subjects in the following format:
1) Schema-Reference: <referenced-subject-1>; <referenced-subject-2>; // without version
2) Schema-Reference: <referenced-subject>+v<version-number>;
Example usage:
First request:
$ curl --location --request POST 'http://localhost:8990' \
--header 'Content-Type: application/json' \
--data-raw '{
"subject": "sub",
"format": "avro",
"definition": { # the definition is not in a string format for readability purposes
"type": "record",
"namespace": "test",
"name": "sub",
"fields": [
{
"name": "state",
"type": "string"
}
]
}
}'
Explanation: while creating the second schema, it:
1) Parses Schema-Reference header
2) Looks up sub subject with version 1 in the repository
3) Creates AVRO parser
4) Parses looked up sub subject's schema definition
5) Parses passed main subject's schema definition (since it parsed sub schema, now it successfully validates test.sub type)
Addresses 3rd solution from #29
Looks up optional
Schema-Reference
header that is suppose to contain referenced subjects in the following format: 1)Schema-Reference: <referenced-subject-1>; <referenced-subject-2>; // without version
2)Schema-Reference: <referenced-subject>+v<version-number>;
Example usage: First request:
Response:
201 Created
Second request (referencing
test.sub
schema):Response:
201 Created
Explanation: while creating the second schema, it: 1) Parses
Schema-Reference
header 2) Looks upsub
subject with version1
in the repository 3) Creates AVRO parser 4) Parses looked upsub
subject's schema definition 5) Parses passedmain
subject's schema definition (since it parsedsub
schema, now it successfully validatestest.sub
type)