Skip to content

More documentation info can be infered from filters and extensions  #2891

Description

@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:

image

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.

Metadata

Metadata

Assignees

No one assigned

    Fields

    No fields configured for Feature.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions