Description
When an API spec defines different response types for several status codes, the code generator does not seem to take this into account and tries to parse the response into a particular object of the model (I suspect that defined for status 200 or maybe the first one found) without checking the code first.
I have an API that returns some json on code 200 and a file in 201, so when I get a file, the generated client tries to parse it as the object and I end up not getting the file contents at all.
I have worked around this by using the _with_http_info calls and passing the _preload_content=False argument to it, but it is rather raw and it introduces a difference to how I check the responses.
Suggest a Fix
The response_type parameter to ApiClient.call_api could be a dictionary of status-code -> response_type. Then depending on the received status code, use one type or the other to process the response.
Description
When an API spec defines different response types for several status codes, the code generator does not seem to take this into account and tries to parse the response into a particular object of the model (I suspect that defined for status 200 or maybe the first one found) without checking the code first.
I have an API that returns some json on code 200 and a file in 201, so when I get a file, the generated client tries to parse it as the object and I end up not getting the file contents at all.
I have worked around this by using the
_with_http_infocalls and passing the_preload_content=Falseargument to it, but it is rather raw and it introduces a difference to how I check the responses.Suggest a Fix
The
response_typeparameter toApiClient.call_apicould be a dictionary of status-code -> response_type. Then depending on the received status code, use one type or the other to process the response.