Unified body encoders/decoders #211
Labels
feature
A new feature!
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently we offer text decoding and JSON serialization as extensions to the base API which are convenient for users, but they aren't very extensible. They also depend on the response body type, which it would be nice to make that more generalized. In addition, these usually read & consume the response stream as a
read_to_end-like API, but it could be more ergonomic to return aResponse<T>instead. For example:Response<Body>and produces aResponse<String>Response<Body>and produces aResponse<T>whereT: DeserializeWe could redesign serialization a bit to make it more general like above and allow users to easily plug in their own formats without needing to manually serialize and deserialize bodies on every request; perhaps some trait you can implement and then attach to an
HttpClientfor some content type.Thinking generally, deserialization often just requires knowing the content type on the response (or some extra headers like content encoding), but serialization usually needs some way for the user to explicitly specify how to serialize. I'm not exactly sure how this will be done yet, but it is worth thinking about.
The text was updated successfully, but these errors were encountered: