You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
The text was updated successfully, but these errors were encountered: