[jira] [Resolved] (CAMEL-19183) camel-rest-openapi: Add an option to set the default content types used in the generated OpenAPI document

["James Netherton (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-19183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Netherton resolved CAMEL-19183.
-------------------------------------
    Resolution: Fixed

> camel-rest-openapi: Add an option to set the default content types used in the generated OpenAPI document
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-19183
>                 URL: https://issues.apache.org/jira/browse/CAMEL-19183
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-rest-openapi
>            Reporter: James Netherton
>            Assignee: James Netherton
>            Priority: Minor
>             Fix For: 4.0-M3, 4.0
>
>
> Many frameworks (springdoc-openapi, SmallRye OpenAPI etc) have an option to specify a default produces / consumes content type for Swagger / OpenAPI documentation.
> It could be useful to have something similar in Camel and allow it to be overridable via the usual .consumes() & .produces() REST DSL options.
> It would fix a slight quirk of how the OpenAPI v3 doc generation is done. If you specify an input body for a verb and omit consumes, then the body config never gets configured and rendered in the API docs (expected since consumes is mandatory when there's a body). But there's no hint in Camel that the consumes part was required. Thus having a default would allow it to always work and you get better dev feedback by being able to have the body content available via the Swagger UI.
> I've seen from posts on stackoverflow.com and elsewhere, where the lack of a default has been a source of confusion for folks when they don't provide produces / consumes in their REST config, and wonder why the API docs are not rendered as expected. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)