Response body not conforming with confluent documentation

[jimmyatgocardless]

When doing a GET /subjects/something/versions/1
this is returned

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

according to the confluent documentation I should get this:

{
    "subject": "something",
    "version": 1,
    "schema": "{\"type\": \"string\"}"
}

that is, the "name" property should be called "subject".

This means that we can't use the confluent client code defined in io.confluent.kafka.schemaregistry.client to interact with the server.

Is this something that you would consider changing?

[tjwp]

Hi @jimmyatgocardless - can you provide a link to the Confluent documentation that you're looking at.

I'm seeing "name" used here in the response: https://docs.confluent.io/current/schema-registry/docs/api.html#subjects

[jimmyatgocardless]

Ahh yeah you're right, I must have confused myself somehow!
Oddly when looking here: https://github.com/confluentinc/schema-registry it shows "subject" in the curl examples, and that is also what their io.confluent.kafka.schemaregistry.client expects.

Anyway since you're conforming to the API documentation I should take it up with them instead, so please feel free to close this issue.

[mikalaisyty]

@tjwp @jimmyatgocardless Actually this Issue is valid, from the docs:

GET /subjects/(string: subject)/versions/(versionId: version)

subject (string) -- Name of the subject that this schema is registered under
id (int) -- Globally unique identifier of the schema
version (int) -- Version of the returned schema
schema (string) -- The Avro schema string

Therefore It makes it not compliant with the API and official client libraries fail on null subject property :(

[tjwp]

The README should probably specify that this registry was developed when the Confluent implementation was at v3.1.0. There has not been a concerted effort to keep up with later changes.

Looking back at the v3.1.0 documentation the field is specified as name: https://docs.confluent.io/3.1.0/schema-registry/docs/api.html#subjects

They may have changed this in a later version.

Changing it here may introduce an incompatibility for existing code that integrates with this registry. I'm not opposed to supporting this, but we may want to make the name of the field configurable, e.g. via an environment variable.

[mikalaisyty]

I understand. Nevertheless, I still have to disagree that it was the case in version 3.1.0.

Yes, when GET all subjects that response is an array of subjects names, however for POST requests the name property of a subject was called subject even in 3.1.0:
https://docs.confluent.io/3.1.0/schema-registry/docs/api.html#post--subjects-(string-%20subject)

I would say this is an inconsistency in Confluent API.

Having an env var for this field - is an option.. Another possible solution for this incompatibility can be the release of a new major version, however I understand that this might be a bit too much :/