I am looking into the best approach to handling versioning in the new OGC API endpoints from a code maintainability perspective.
In WFS an "adapt" call is used to match a request to an embedded subclass of the request type (see for example https://github.com/geoserver/geoserver/blob/de184b2f9ed9a844b5291dd163e772132a07689b/src/wfs/src/main/java/org/geoserver/wfs/request/GetFeatureRequest.java#L28 and https://github.com/geoserver/geoserver/blob/de184b2f9ed9a844b5291dd163e772132a07689b/src/wfs/src/main/java/org/geoserver/wfs/request/GetFeatureRequest.java#L196 ) Along those lines In the OGC API we could use a Path variable to determine which subclass or version of the method to call. An example of this approach can be found here: https://github.com/turingtestfail/geoserver/blob/bb764ec698dae9db627af452d3a5e4404fa2d926/src/community/ogcapi/ogcapi-maps/src/main/java/org/geoserver/ogcapi/maps/MapsService.java#L114 The downside of this approach would be that if major version changes of the OGC API represented big differences the parent classes could become large and unwieldy. An alternative to the subclass approach would be to organize things by package - an example of this approach can be found here: https://github.com/turingtestfail/geoserver/blob/e69867256e2124677233faad94ef4a095a7f0259/src/community/ogcapi/ogcapi-tiles/src/main/java/org/geoserver/ogcapi/v1/TilesService.java#L80 The downside of this approach is that multiple packages could end up with redundant code and a confusing file structure for maintainers. Thanks in advance for any feedback, Joe Miller
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
