Versioning of services

[guleri]

Is there a way to handle different versions of the same service or data set? Our services, especially the data schemas, are bound to change, and it would be nice to be able to let people who use our APIs to keep using an old version if we make a new one.

Maybe it's there somewhere, but I haven't been able to find anything about this in the standards, or in the ldproxy documentation.

[cportele]

There is currently nothing in the standards about versioning of APIs or datasets. There has been discussion about fine-grained versioning of features (opengeospatial/ogcapi-features#430, opengeospatial/ogcapi-features#764), but this is different from your request which is more about different snapshots of the data or maybe different API capabilities over time.

Your two versions are basically two different APIs and can be published as such. Of course, the information about their relationship is only available to users from reading the description (if the information is included in the description) or implicitly from the API naming (e.g., http://localhost:7080/rest/services/apiId_v1 and http://localhost:7080/rest/services/apiId_v2).

ldproxy supports an (currently not well documented) configuration option in the services/API configuration apiVersion. The value is a number. If it is set to, for example, apiVersion: 1 then the landing page of the API will be at http://localhost:7080/rest/services/apiId/v1 instead of http://localhost:7080/rest/services/apiId. However, currently there is not yet support for multiple versions of an API in the same deployment (e.g., v1 and v2). It should not be complex to support this, but currently it is not yet supported.

[guleri]

Thanks,
I really hope that API versioning will be part of the standards at some point, because I feel this that how the best practice for how to handle this is a reoccurring theme of discussion when it comes to REST APIs in general.

To create a new service with v2 is an obvious solution that will work, but it feels like, in lack of a better word, a "dirty" way of doing it.

The ldproxy way you're describing, if it will support more than one version, sounds like a good idea, but it would be even better if it was something that was agreed upon between different implementations.