Consider dropping GraphQL via GET (at least for Mutations) about graphql-over-http HOT 10 CLOSED

In PostGraphile's server, we do the parsing in the server (and validation, for that matter), before later handing off to execute (import { execute } from 'graphql') with the parsed document (AST). For a GraphQL server I think it's not unreasonable to expect the server to do superficial parsing of the document sufficient to determine the operation type; but maybe we could limit this requirement to only servers supporting GET?

I 100% agree that mutations MUST NOT be available over GET. I know there are people doing this currently, that's not sufficient to justify allowing it to me.

from graphql-over-http.

The Apollo Client HttpLink already opts mutations out of GET requests:

https://github.com/apollographql/apollo-client/blob/287aa465d56fea7d2171533921e73b78caac26a7/src/link/http/createHttpLink.ts#L99-L104

from graphql-over-http.

Query is unfortunately a very overloaded term.

I am aware, that is why I specifically alluded to query operations as opposed to mutation operations.

We seem to agree that read-only requests (query operations) are fine, so maybe the title can reflect that we should Consider dropping GraphQL mutations via GET.

from graphql-over-http.

To be clear: Are you recommending to remove sending GraphQL query operations through GET, too?

Since query operations are prescribed to be idempotent by the GraphQL spec, using GET is perfectly fine for them. It can even be advantageuous for caching.

from graphql-over-http.

Query is unfortunately a very overloaded term: the problem are not queries which are only reading, but the problem are queries which change something (mutations).

from graphql-over-http.

@spawnia I agree that dropping GraphQL mutations only is a theoretical option. Not sure this is a good practical option as it requires a level of understanding of the query which is normally not available in the transport layer (the query must be parsed in order to say it is a query or mutation).

I amended the title to make it more clear.

from graphql-over-http.

I would recommend to make it optional at least: all GraphQL servers in production I know about don't support GET and only POST.
Parsing and validating a Mutation via GET before it is rejected is doable of course, but this extra effort should be optional at least.

from graphql-over-http.

We rely on GET for queries that don't contain mutations in order to support caching via cache-control and etag headers, both in edge caches and on clients.

Much as I'd prefer to just use POST everywhere, which avoids long URL limitations, it's extremely difficult to do caching of POST responses at both these layers. Clients that follow the HTTP spec will refuse to reuse POST responses, and only some edge caches/CDNs allow POST caching (for example, with enough configuration Varnish and Akamai do, but AWS CloudFront does not).

from graphql-over-http.

from GraphQL over HTTP Spec

A server MUST accept POST requests, and MAY accept other HTTP methods, such as GET.

Isn't it better to use the HTTP GET method in the query operation?

If so, shouldn't the specification include a statement that GET is recommended for query operations?

If not, what is the advantage of POST over GET in query operation?

from graphql-over-http.

Please raise that as a separate issue so it can be assigned to a milestone and discussed.

from graphql-over-http.