Hacker News Reader

Comment by brailsafe | Hacker News Reader

How does GraphQL allow you to not worry about those things?

GraphQL only uses two HTTP methods (GET and POST). But they actually don't differentiate in their function: you can do any type of reading/writing kind of queries in both GET and POST requests[1]. POST requests are used because they allow for larger bodies.

GraphQL defines the format of the reponse in case of errors[1]

GraphQL doesn't use HTTP status codes to communicate out-of-the-ordinary conditions. You can expect to always get HTTP status 200[1]

The data response is a mirror of the query you sent in with the data present[2]

How to query for data is explicitely laid out[3]

How to send in parameters is explicitely laid out[4]

[1] https://graphql.org/learn/serving-over-http/ [2] https://graphql.org/learn/ [3] https://graphql.org/learn/queries/#fields [4] https://graphql.org/learn/queries/#variables

And when intermediate proxies happily retry your small “delete the most recent record” request because it was a GET which is, in the rest of reality, guaranteed not to alter state on the receiving server except in the corner of the internet you’ve defined as your own it’s destructive?

You can use GET for read queries and POST for write queries.

Edit: actually you made me think a little bit more about this, if you can make your mutations idempotent, spurious retried POST requests shouldn't be a problem at all. However "delete the last record" is not an idempotent operation by definition but also one you wouldn't use in the real world - usually you delete by ID.

Edit 2: it's easy to make the server reject mutations sent via GET.

RPC over HTTP pretty much always goes through POST, sometimes with the option of using GET for querying as an optimisation.

For graphql specifically, if you allow GET-ing the GraphQL endpoint (which usually isn't the case by default), it's trivial to ensure only queries go through that method.

AFAIK graphql does have response error codes. You should always have response error codes no matter the form of api. They are semantic info.

GraphQL does not have response error codes. It only dictates that any response that has errors, should have an "error" field. It is not defined what this error field should contain, it can be a string or an object with a code and text, etc...

I could be wrong. Some of the graphql servers I have interacted with have given me useful error codes. E.g GitHub.

We do have nice wrappers around the request to raise a proper named exception regardless so it doesn’t matter.

Reply on news.ycombinator.com