Open tyranron opened 7 months ago
@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
Resolves #1120
Synopsis
Checklist
extensions
parameter toGraphQLRequest
.null
correctly for optionalGraphQLRequest
parameters and emptiness in GET query params.GraphQLRequest
.Accept
HTTP header and its priority.405 Method Not Allowed
.Content-Type
in POST requests.application/json
responses.Integration
juniper_actix
juniper_axum
juniper_hyper
juniper_rocket
juniper_warp