GraphQL over HTTP spec compliance (#1120)

[tyranron]

Resolves #1120

Synopsis

Currently in draft but it is an official project:

https://graphql.github.io/graphql-over-http/draft/

Checklist

• [ ] Correct media type for responses and appropriate response codes.
• [ ] Add extensions parameter to GraphQLRequest.
• [ ] Handle null correctly for optional GraphQLRequest parameters and emptiness in GET query params.
• [ ] Consider "well-formness" of GraphQLRequest.
• [ ] Consider Accept HTTP header and its priority.
• [ ] Disallow mutations for GET requests with 405 Method Not Allowed.
• [ ] Consider strict and non-strict semantics regarding Content-Type in POST requests.
• [ ] Support additional validation rules.
• [ ] Provide correct legacy support for application/json responses.

Integration

• [ ] juniper_actix
• [ ] juniper_axum
• [ ] juniper_hyper
• [ ] juniper_rocket
• [ ] juniper_warp

[tyranron]

@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.

[LegNeato]

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