More documentation info can be infered from filters and extensions

[tigitz]

Hello,

I was trying to go the "design first" route for a simple api by coding some resources without wiring them at first and then generating the swagger/open api spec from it.

I found myself adding more and more stuff about filters in my custom swagger documentation normalizer that I thought could already be inferred.

Here's a short preview:

OrderFilter: the allowed values are desc and asc, so it could generates the following in addition:

{
  "parameters": [
    {
      "type": "string",
      "enum": [
        "asc",
        "desc"
      ]
    }
  ]
}

Resulting in a nice select in swagger ui:

Items per page: When enabled, api-platform knows about the default value, the maximum and minimum value per resource and collection operation.

BooleanFilter & ExistsFilter: enum of true,false,1, 0

GroupFilter: It seems technically possible to infer the allowed serialization groups and therefore producing the right enum documentation

PropertyFilter: It seems technically possible to infer the exposed properties and therefore producing the right enum documentation

I might have overstepped some edge cases that make my assumptions wrong though. Let me know if it's the case.

Anyway, if these suggestions are deemed valid and interesting enough, I could work on them if needed.

[dunglas]

But +1 on my side to support add support for this!

[soyuka]

#2254