Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify the use of HTTP GET and POST request #205

Open
TomokiMiyauci opened this issue Jul 19, 2022 · 2 comments
Open

Clarify the use of HTTP GET and POST request #205

TomokiMiyauci opened this issue Jul 19, 2022 · 2 comments
Milestone

Comments

@TomokiMiyauci
Copy link

from GraphQL over HTTP Spec

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

For semantics and performance (caching, etc.), it seems to me that it is recommended to use GET for the query operation.

If the options are not equivalent, it is necessary to clarify which is more appropriate.

@benjie benjie added this to the 1.0 Release milestone Jul 19, 2022
@spawnia
Copy link
Member

spawnia commented Jul 19, 2022

One possible concern I could see with GET requests is the limited length of a URL. Some web server defaults:

When fragments, unstripped comments, lots of variables and multiple levels of nesting are involved, payloads can get quite large. A quick look at our application logs showed a few queries above 1000 characters.

@TomokiMiyauci
Copy link
Author

@spawnia

RFC 7230

It is recommended that all HTTP senders and recipients support, at a minimum, It is recommended that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.

That is certainly true.

What do you think about caching of query operation?
Caching using the POST method seems to be possible, but I am not familiar with it.

Some implementations have complex mechanisms for handling cache on the client side, but I doubt it is really necessary.

It would be helpful to have a description of caching in the Spec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants