You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Michael Würsch (Jira)" <ji...@apache.org> on 2020/10/13 07:12:00 UTC
[jira] [Created] (CAMEL-15676) openapi-restdsl-generator -
redundant content-types with multiple responses
Michael Würsch created CAMEL-15676:
--------------------------------------
Summary: openapi-restdsl-generator - redundant content-types with multiple responses
Key: CAMEL-15676
URL: https://issues.apache.org/jira/browse/CAMEL-15676
Project: Camel
Issue Type: Bug
Components: tooling
Reporter: Michael Würsch
openapi-restdsl-generator and accordingly the camel-restdsl-openapi-plugin for maven generate problematic code/xml if there are multiple responses with the same content-type defined for a given path and operation.
Example:
{code:json}
...
"responses": {
"200": {
"content": {
"application/json": {
...
}
},
"description": "Updated pet."
},
"201": {
"content": {
"application/json": {
...
}
},
"description": "Created pet."
}
}
...
{code}
will result in:
{code:xml}
<rest>
<put consumes="application/json" produces="application/json,application/json" uri="/pet">
<param name="body" required="true" type="body"/>
<to uri="direct:rest1"/>
</put>
</rest>
{code}
The problematic part is the comma-separated list as the value of the produces-attribute, where application/json is listed twice. The Camel route will then, per default, return "application/json,application/json" as the content-type.
This invalid content-type causes some problems in third-party tools and frameworks, for example the Citrus testing framework. Although a simple work-around for the example above is to explicitly set the content-type header in the Camel route, I think the current behavior could be easily improved by modifying org.apache.camel.generator.openapi.OperationVisitor to use a set instead of a list for emitting the operationLevelProduces.
This would not fix cases, where there are multiple responses with different content-types, such as "application/json,text/xml". But I assume that they are a little bit less common nowadays (at least for us).
I will follow-up with a pull-request.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)