@LegNeato after investigating it closely, the rabbit hole seems to be way deeper that I thought it would be. There are quite a lot of nuisances and details to be handled properly regarding different media types (for example, response codes for application/json and application/graphql-response+json are treated very differently), and moreover, spec implies few points for extension by user-side, while the core should remain.

Implementing all this separately for each integration crate would be painful and fragile. Moreover, integration crates are not doing well with extensibility. That's why, to implement this properly, it seems right to introduce a new juniper_graphql_http crate, providing a core http-crate-based implementation and being framework-agnostic, just as we have the juniper_graphql_ws crate for GraphQL over WebSocket specs.

This, however, quite a huge and time-consuming task, so I decided to move it from 0.16 milestone to 0.17 one.

Make sense to me! I've been thinking that we'd probably need something similar, mirroring the http / tower stack