Flexible route parameterization for GeoServices

[rgwozdz]

For services with a large number of layers, support for arbitrary folder depth would be very useful. For example:

/es/rest/services/Parent/FeatureServer
/es/rest/services/Parent/Child/FeatureServer
/es/rest/services/Parent/Child/SubChild/FeatureServer

Currently with the :host/:id route format, the /Parent/Child path is possible (required?) but to my knowledge you can't arbitrarily nest services. When using the Elasticsearch provider with the current version of Koop, the third URL would error with:

Cannot GET /es/rest/services/Parent/Child/SubChild/FeatureServer

If you get rid of the :host parameter, will it be possible to support this arbitrary nesting or will both the second and third URL's report an error? Would the idea be to change the route something like this?

/$providerNs/rest/services/:id*/FeatureServer

Then using the third URL as an example, req.params.id would be Parent and req.params.0 would be /Child/SubChild and the provider would be responsible for handling that appropriately.

Thanks for providing this roadmap, this is all helpful planning our project moving forward.

This would be for organizational purposes, so we can structure our services in folders.

Here's an example from the ArcGIS Online sample server:
https://sampleserver6.arcgisonline.com/arcgis/rest/services
https://sampleserver6.arcgisonline.com/arcgis/rest/services/LocalGovernment/Recreation/FeatureServer

The base service has a mix of folders and services to better organize all of the layers. If the URL pattern was changed to /es/rest/services/:id/FeatureServer it would not be possible to mimic this sort of structure. You would be limited to listing out a flat list of layers, which is not desirable for servers with a lot of layers.

If the URL pattern was instead /es/rest/services/:id*/FeatureServer, arbitrary nesting could be supported. Using the above URL as an example, the req.params object would look like this:

{
  id: "LocalGovernment",
  0: "/Recreation"
}

The id property will contain everything up to a /, and the 0 property will contain everything else up to /FeatureServer (including slashes). The provider would be responsible for interpreting that, but this would allow any depth in the URL structure.

Originally posted by @schmidtk in #386 (comment)