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)