How to disallow unknown query parameter?

The operation object allows folks to specify parameters, but how can I express that no unnamed parameters may be accepted?

We’ve had issues where clients are passing in query parameters thinking that they’re accepted when actually they are not.

How do folks feel about introducing something like additionalQueryParameters for parameters?

/foo:
  get:
    parameters:
      limit:
        in: query
      offset:
        in: query
    additionalQueryParameters: false
    ...

Then when folks do GET /foo?start=xxx-xxx-xxx they’ll get an error instead of a silent failure.

Other links on the web:

• https://stackoverflow.com/questions/58187233/is-it-possible-to-disallow-unknown-query-parameters-in-an-openapi-v3-spec
• https://github.com/cdimascio/express-openapi-validator/issues/133
• https://github.com/opengeospatial/ogcapi-features/issues/128
• https://softwareengineering.stackexchange.com/a/311489

[MikeRalphson]

If we moved to representing all in:query parameters as an object described by a single JSON schema, then we would get this functionality ‘for free’ with the existing additionalProperties keyword.

[smikulcik]

So where does this put us today.

@savage-alex you make a good point about what we actually should and shouldn’t document in our specifications.

Perhaps we should ask, “when would it be desirable to permit undocumented query parameters?” If we have no good use cases for it, maybe we should by default specify that implementations should reject unknown query parameters in general.