Add an endpoint to display the bridge version.

[granzoto]

Nowadays the Kafka bridge only displays its version in the startup. It would be nice to have an endpoint to display its version.
Let's suppose we have a new feature available only on versions > 0.13.0. With this /version endpoint a client can easily check if the version he is connecting matches the minimal version for that feature.

[ppatierno]

We already expose the OpenAPI specification on the /openapi endpoint. Of course, it's all about the API and doesn't contain any details about the bridge. For example, the info.version field is the version of the API that could be not the same as the version of the bridge implementing that API version.
Said that we have two ways for doing this:

• using so-called "OpanAPI Extensions" (https://swagger.io/docs/specification/openapi-extensions/) adding a x-bridge-version (under info section) so that the client can just queries the /openapi endpoint getting the bridge versin from it.
• exposing a new /version endpoint.

The problem with the first solution is about having the OpenAPI spec files aligned with the version we are releasing (maybe we should automate "something" via make), while the second solution is fully dynamic.

[elakito]

Hi,
I thought about this sometime ago. Maybe we could use the root path GET / to return a version file like what Kafka-connect returns at GET /? Confluent's Kafka-rest returns an empty json while Strimzi Kafka-bridge currently returns 404 not found. I think returning something other than 404 would be good and we could return the version info.

Regarding the openapi spec approach, I have a related question. I wanted to use a template file and inject other values (e.g., for basePath) so that when it is hosted behind a gateway, we could inject the correct basePath when the gateway is passing x-forwarded-prefix header to the bridge host. If we take this approach, we can also inject the version into the document.

[ppatierno]

@elakito but the openapi json file is a resource so what you said should happen at compile time when building the jar. So if you want to change the basePath you should recompile the bridge jar. Did I get it right what you mean?

[ppatierno]

thinking more I would agree with @elakito about using the root / for getting information about the bridge which could be initially just the version. @stanlyDoge wdyt? I see you are working on a PR for this.

[sknot-rh]

Yes, probably it is a better idea to have this prepared for more info entries, not just version.

[elakito]

it sounds good about using the root path to provide the bridge info.

@ppatierno Regarding the basePath value, you don't want to prepare the spec file for each deployment variant to switch the base path. If we have a Kafka-Bridge instance behind a gateway and the gateway is taking requests at path /app/kafka-bridge and reverse-proxing to the bridge instance at path /, it would be nice if the spec is returned with the basePath being set to /app/kafka-bridge instead of /, derived from the x-forwarded-prefix header of the request. In this case, the client can, for example, issue a request at /app/kafka-bridge/topics instead of /topics, knowing the correct basePath for this particular instance. Similarly, the host value could be set using x-forwarded-host (But the host property is optional in v2, so we could simply remove it to avoid this situation).

I am currently using a small translation code at the gateway to do this adjustment and I thought it would be nice if it is done directly at the bridge. But I don't know if other people also want such a dynamic translation.

[ppatierno]

@elakito can you move this to an issue for discussion, please? Thanks!