Improve GraphQL API response HTTP status codes
Currently with our GraphQL API, there are several possible response codes:
- 200 - no problems, and
data
contains what was requested - 200 - some expected and caught exception, and response contains errors in the
errors
block - 200 - some query issue (try this by submitting the query "nonsense")
- 500 - there was an unhandled exception (try this by putting
raise "oh noes"
into a resolver) - others, such as 502 - infrastructure related issues such as timeouts (e.g. query too big)
The REST API uses HTTP codes, which the monitoring aggregators can easily make use of. There is some concern that GraphQL endpoint errors aren't easily parsable because they do not follow this paradigm.
Apollo or Relay may handle these things seamlessly.
Should we handle GraphQL differently (read: use response codes) to make it easier for monitoring and the frontend?
Edited by Grzegorz Bizon