@TAEWOOKK

Image

Is your feature request related to a problem? Please describe. Yes. When our API Request DTOs contain enum fields, our front-end developers or API consumers have to click the "Schema" tab in Swagger UI just to see what the valid string values (keys) are and what they mean.

This is inconvenient. The alternative is to manually write all enum details (e.g., "ACTIVE: Means the user is active...") into the @operation(description = "...") annotation for every API.

This manual process is tedious, error-prone, and violates the DRY (Don't Repeat Yourself) principle. If an enum is updated (e.g., a new value is added), developers must remember to manually update the description string, which is often forgotten.

What is the actual result using OpenAPI Description (yml or json)? The operation.description is empty or only contains text that was manually entered. It does not automatically reflect the details of enum fields used in the request.

Describe the solution you'd like I would like springdoc-openapi to provide a built-in feature or a standard OpenApiCustomizer that automatically scans the parameters of an operation (especially @RequestBody DTOs).

If it finds enum fields, it should:

Find all constants of that enum.

Conventionally look for a specific method on the enum constant (e.g., getDescription(), getValue(), or similar) to get a human-readable description.

Automatically append a formatted (e.g., Markdown) list of the enum constants and their descriptions to the operation.description.

What is the expected result using OpenAPI Description (yml or json)? The operation.description field should be automatically enriched. For example:

(Existing manual description...)

Markdown

---

✅ status Enum Details

• ACTIVE: Represents an active user.
• INACTIVE: Represents an inactive user.
• PENDING: Represents a user pending activation.
  Describe alternatives you've considered

Manual Annotation: Manually writing this information in @operation or @Schema for every single API. This is the current, inefficient workaround.

Per-Project Customizer: Using a custom OpenApiCustomizer in every project. It would be much better if this was a built-in, configurable feature of springdoc-openapi itself.

Additional context I have already implemented a proof-of-concept OpenApiCustomizer that achieves this. If this feature is desirable and you are open to contributions, I would be happy to open a Pull Request with the implementation.