Adapt returned response header to provide version information

[Kate-Lyndegaard]

Feature Description:

The full version number is added in the response headers for every API call in the format: API-Version: 1.0.2.

A pull request is made so that this feature can be available as an optional extension to the core deegree OGC API product.

Additional information:

This issue is related to the Dutch API requirement labeled AP-57:

API-57: Return the full version number in a response header

Since the URI only contains the major version, it's useful to provide the full version number in the response headers for every API call. This information could then be used for logging, debugging or auditing purposes. In cases where an intermediate networking component returns an error response (e.g. a reverse proxy enforcing access policies), the version number may be omitted.

The version number must be returned in an HTTP response header named API-Version (case-insensitive) and should not be prefixed.

An example of an API version response header:
API-Version: 1.0.2

Definition of done:

The full version number is added in the response headers for every API call in the format: API-Version: 1.0.2.

A pull request is made so that this feature can be available as an optional extension to the core deegree OGC API product.

This feature should be optional.

[tfr42]

Thank you for opening that feature request. We would appreciate if this feature can be enabled by configuration.

Please have a look into the issue deegree/deegree3#1102 and the related pull request deegree/deegree3#1442 for a similar topic related to the deegree webservices.

[kapil-agnihotri]

Thank you @tfr42 for your suggestion on the feature request.

We would like to know what would be the accepted configuration by the deegree team for adding version information in the response header.

We think of three options for this:

1. the configuration can be introduced in a new configuration file with global settings or
2. it can be extended to an existing configuration file that has a global setting(however, we do not find any such file) in the workspace or it can also be added to a feature specific setting for e.g. to features.xsd. or
3. use a simpler mechanism for global configuration (e.g. environment variables).

If any of these options are acceptable to you then can you please also provide some suggestions on the implementation details for e.g. preferred name of the new global configuration file, its desired location, etc.

[tfr42]

We are in favour of option 3 using a global configuration. Please have a look on the approach we have used for the deegree webservices core documented in https://github.com/deegree/deegree3/blob/main/deegree-services/deegree-webservices-handbook/src/main/asciidoc/appendix.adoc and the class https://github.com/deegree/deegree3/blob/main/deegree-core/deegree-core-commons/src/main/java/org/deegree/commons/utils/TunableParameter.java
Please review if the TunableParameter can be used to set the version of the API to the HTTP Header and also to the OpenAPI document available at /api.