After reviewing several HTTP implementations in Rust I realized that all of them seem to implement message body as "something to read". For example, all of these are used as both request AND response bodies:
- https://docs.rs/http-body/0.2.0-alpha.3/http_body/trait.Body.html
- https://docs.rs/http-service/0.3.1/http_service/struct.Body.html
- https://docs.rs/hyper/0.13.0-alpha.4/hyper/body/trait.Payload.html
Which means that when implementing a server endpoint, you are expected to provide a source of bytes that will be read whenever the server decides to read.
But what if you need to control how the body is written into the response stream; e.g., when individual chunks need to be flushed exactly when needed?
This is often required in order to implement something like Server-Sent Events or similar long-poll protocols.
May other language frameworks (like Go or Java) model server response bodies (as well as client request bodies) as "something to write" -- the implementation controls when to write and flush the bytes.
In Rust, and perhaps just those frameworks specifically, what is the reasoning for representing both request and response bodies as the same type/trait?
Is there an HTTP framework (preferably async/await friendly) that doesn't?
