Repository navigation
Add QUERY verb - #411
Add QUERY verb#411martinbonnin wants to merge 13 commits into
QUERY verb#411Conversation
|
How about a bit more DRY? For example:
Then any future changes to the POST requirements are inherited by the QUERY requirements. Or are there more differences? |
There is one difference in the paragraph that But that's something you call out at the beginning of your version. I think the "condensed" part is easier to read and maintain but is a bit less clear. Both work for me. |
Co-authored-by: Benjie <benjie@jemjie.com>
Co-authored-by: Benjie <benjie@jemjie.com>
|
Notes from July wg:
|
|
Few notes:
|
|
Thanks for the review! Comments inline
I think so too? But I might be missing some context.
Yup. Would recommend addressing outside this PR.
Sorry I missed that part of the discussion yesterday. The caching is outside this spec IMO? Browsers/CDN/etc.. can use HTTP caching with
We should definitely specify incremental delivery and subscriptions over websockets somewhere. I expect it to be a much larger endeavour than
I'm not 100% clear on the impacts there. Do we have a documented security issue using
I'd prefer doing this in a separate PR. And probably address
100%
Addresed in 7a6701f
Agreed. Not 100% sure how to do it +
Addressed in 24d2675. I made this as a "Note", not sure how to deprecate otherwise. |
| status code should be used: | ||
| - If a mutation is attempted via the `GET` verb, status code `405` SHOULD be | ||
| used. | ||
| - If a mutation is attempted via the `QUERY` verb, status code `405` SHOULD be |
There was a problem hiding this comment.
Shouldn't this be 422 now (see above)?
If yes, GET should likely be changed as well?
There was a problem hiding this comment.
Shouldn't this be 422 now (see above)?
Yup, 100%. This was a bad merge. Thanks for catching this 🙏
If yes, GET should likely be changed as well?
Good question. 405 has been around for a while and this hasn't been an issue. See also #205 (comment). I'll defer to @benjie on this one.
Support the graphql-over-http QUERY verb (graphql/graphql-over-http#411). - Register the GraphQL route for both POST and QUERY - Reject mutations over QUERY with 405 Method Not Allowed, as required by the spec (including batched and persisted queries) - Bump fastify to ^5.12.1, which natively supports the QUERY method
* feat: support the HTTP QUERY method (RFC 10008) Support the graphql-over-http QUERY verb (graphql/graphql-over-http#411). - Register the GraphQL route for both POST and QUERY - Reject mutations over QUERY with 405 Method Not Allowed, as required by the spec (including batched and persisted queries) - Bump fastify to ^5.12.1, which natively supports the QUERY method * fix: only register the QUERY method when Fastify supports it Fastify added support for the HTTP QUERY method (RFC 10008) in v5.11.0. On older versions, registering a route with the QUERY method throws FST_ERR_ROUTE_METHOD_NOT_SUPPORTED during plugin registration, preventing mercurius from booting at all. Feature-detect support via app.supportedMethods and skip the QUERY registration on older Fastify versions, where QUERY requests simply fall through to a 404.
greem::http::handle takes the parts of an HTTP request (method, query string, Content-Type, Accept and the body) and answers a Response. It serves GET, and POST and QUERY with an application/json body, and negotiates Accept with q-values between application/graphql-response+json, legacy application/json and multipart/mixed. Status codes follow the GraphQL-over-HTTP draft: 400 for a body or document that does not parse, 422 for other request errors and for malformed parameters, 294 for data alongside errors, 405 for a mutation over GET, and 406 and 415 for media types it cannot serve. QUERY (RFC 10008) runs queries only and answers a mutation with 422, as graphql/graphql-over-http#411 proposes ahead of the draft. Request errors carry a RequestErrorKind, so the status follows the step that failed. The http feature converts from http::request::Parts and into an http::Response whose body is an http_body::Body. The axum example and greem-bench's serve binary now hand each request to it instead of keeping their own copies of the same handler. ADR-0012 records following the draft where graphql-http's audits disagree. Closes #21 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
greem::http::handle takes the parts of an HTTP request (method, query string, Content-Type, Accept and the body) and answers a Response. It serves GET, and POST and QUERY with an application/json body, and negotiates Accept with q-values between application/graphql-response+json, legacy application/json and multipart/mixed. Status codes follow the GraphQL-over-HTTP draft: 400 for a body or document that does not parse, 422 for other request errors and for malformed parameters, 294 for data alongside errors, 405 for a mutation over GET, and 406 and 415 for media types it cannot serve. QUERY (RFC 10008) runs queries only and answers a mutation with 422, as graphql/graphql-over-http#411 proposes ahead of the draft. Request errors carry a RequestErrorKind, so the status follows the step that failed. The http feature converts from http::request::Parts and into an http::Response whose body is an http_body::Body. The axum example and greem-bench's serve binary now hand each request to it instead of keeping their own copies of the same handler. ADR-0012 records following the draft where graphql-http's audits disagree. Closes #21 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
greem::http::handle takes the parts of an HTTP request (method, query string, Content-Type, Accept and the body) and answers a Response. It serves GET, and POST and QUERY with an application/json body, and negotiates Accept with q-values between application/graphql-response+json, legacy application/json and multipart/mixed. Status codes follow the GraphQL-over-HTTP draft: 400 for a body or document that does not parse, 422 for other request errors and for malformed parameters, 294 for data alongside errors, 405 for a mutation over GET, and 406 and 415 for media types it cannot serve. QUERY (RFC 10008) runs queries only and answers a mutation with 422, as graphql/graphql-over-http#411 proposes ahead of the draft. Request errors carry a RequestErrorKind, so the status follows the step that failed. The http feature converts from http::request::Parts and into an http::Response whose body is an http_body::Body. The axum example and greem-bench's serve binary now hand each request to it instead of keeping their own copies of the same handler. ADR-0012 records following the draft where graphql-http's audits disagree. Closes #21 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
5 participants
See https://www.rfc-editor.org/rfc/rfc10008.html and ecosystem adoption
QUERYis an idempotent cacheable request with a body that maps quite well to GraphQL queries.This editorial duplicates a bit of text but since this is a spec and not a novel, I'd rather have duplication than missing information. Maybe the JSON encoding part could be factored in but not sure how.