Is your feature request related to a problem? Please describe.
There are cases where the having more flexible content-type response header value makes sense. Some come from the content type the client requests/supports, other is where the server picks what is best content-type depending on the logic.
Describe the solution you'd like
Initially I think that c.otherResponse should be considered as place to implement this feature in the contract. One option is to have the contentType be an array with all options instead of string, where the body would be union of the schemas. But more appropriate would be I think to have union of the whole response.
Is your feature request related to a problem? Please describe.
There are cases where the having more flexible content-type response header value makes sense. Some come from the content type the client requests/supports, other is where the server picks what is best content-type depending on the logic.
Describe the solution you'd like
Initially I think that
c.otherResponse
should be considered as place to implement this feature in the contract. One option is to have thecontentType
be an array with all options instead of string, where the body would be union of the schemas. But more appropriate would be I think to have union of the whole response.Something like this:
On the server side, probably returning
content-type
underheaders
would be sufficient?Describe alternatives you've considered
The current workaround is to have separate response entries and disregard the HTTS status code: