Return raw response #225
Return raw response #225
Conversation
| @@ -115,6 +115,8 @@ def has_content(response_spec): | |||
| content_value = umsgpack.loads(response.raw_bytes) | |||
| if op.swagger_spec.config['validate_responses']: | |||
| validate_schema_object(op.swagger_spec, content_spec, content_value) | |||
| if op.swagger_spec.config['return_raw_response']: | |||
There was a problem hiding this comment.
This config seems more related to "HTTP" handling and not swagger. I would suggest adding this into bravado implementation as request option so you could enable this behavior on per request base.
|
I looked at request_options but I didn't find a way to implement the same functionality (without larger code changes). Essentially what I'd like to do is:
All of this logic (response validation, response decoding, ...) is called in bravado_core.response.unmarshal_response so if I'd move the new code to a higher level I'd have to duplicate some of the unmarshal_response logic somewhere else (e.g., response validation, content-type detection, ...). For return_raw_response I followed the approach used for the use_models config option which is similar as it also determines how the response is returned. How would an implementation that uses request options look like? Would I have to duplicate the deserialization logic (json, msgpack) and the response validation logic somewhere else? |
|
@gstarnberger fair point ... During hackathon @sjaensch started to work a bit on async io bravado and we were discussing if it could make sense to move into bravado the logic for handling requests, so that could be already a sort of solution for you. For your use case, I was thinking to add a request option (similar to Let me sync better with @sjaensch tomorrow morning, he could eventually have better ideas about your case 😄 |
Adds a new config option "return_raw_response" that returns the raw decoded response (after json/msgpack decoding, skipping the call to unmarshal_schema_object).