Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Support BinaryIO for streaming request and response bodies (#303)
## Changes This PR adds support for non-application/json requests and responses. This PR is divided into two parts: **Support setting headers per request**. The `do` method of the ApiClient class is expanded to accept one new parameter, `headers: dict`, and all callers are expected to pass a map of headers to be included in the request. As the allowed content types for requests and responses are known from the OpenAPI specification, callers must construct the request header map in code generation and pass it to the ApiClient. The default "Content-Type: application/json" header is removed, as each request should specify its own Content-Type and Accept headers. This is done in #302. **Add support for streaming request and response bodies to support non-application/json requests/responses**. Today, serialization of requests is done in the ApiClient. This implies that ApiClient needs to be able to serialize a request purely based on the parameters provided to it via headers, the request body, etc. In this proposal, the serialization is specified by the caller depending on whether the `body` or `data` field of `do()` is used: `data` should be used for already-serialized data, such as BinaryIO or file-like objects, and `body` should be used for JSON objects. One important caveat about streaming responses is that callers are required to close the streams when they are done using them. To do this, we may need to expose the raw Response object so that users can use `with w.service.method() as response:` to automatically close the response when they are done reading. ## Tests <!-- How is this tested? Please see the checklist below and also describe any other relevant tests --> - [ ] `make test` run locally - [ ] `make fmt` applied - [ ] relevant integration tests applied
- Loading branch information