Pass extra parameters to requests to allow for custom behaviour down the line

[Moritz-Langer]

Is your feature request related to a problem? Please describe. For some requests there might be a need custom behaviour. This can be implemented using extra parameters in the request which are evaluated later on in providers or plugins. If they're not passed to the request nothing happens. When for example &foo=bar is added to the request this should be available in a dictionary passed to the providers for additional functionality.

Describe the solution you'd like Request can be in the form http://localhost:8080/collections/lakes/items?&foo=bar and a dictionary containing 'foo':'bar' is avaialable in the providers.

Describe alternatives you've considered

Additional context @tomkralidis @totycro we talked about this at the vienna code sprint.

[Moritz-Langer]

@francescoingv Do you mean the metadata of the table behind the collection? A Use-Case: we have a filter for a maximum area for queries with bbox. This makes sense, since some layers might contain a lot of features and they should not be queried at every zoom level and it should not be allowed to, for example query all land properties for the entire USA. However there are certain cases where we want this to happen. Then there might be a parameter passed to the request that could be called allow_big_bbox. This can not be found in the Database Table but can be attached with functionality in a plugin.

There are certainly more use cases, but this one illustrates the problem.

[francescoingv]

@Moritz-Langer Sorry, I was focused on process only, and missed to view the bigger picture for the other specification.

I would better rephrase my question: what are the ogc-api specifications involved in your isssue?

[Moritz-Langer]

This is related to OGC API Features but stretches point 7.6 with additionalProperties https://docs.ogc.org/is/17-069r4/17-069r4.html#query_parameters

However I think this would still be useful because it provides flexibility for projects using pygeoapi without having to rely on custom implementation in the core of the request logic. Custom implementation comes into play with installable plugins but not at the pygeoapi-core level and allows for projects to define specific behavior later on. A prerequisit is that arbitrary parameters can be passed to the request.