Description
Clients that are used to REST services can easily use GraphQL just as if it was a REST endpoint that requires POSTing a query string and returns the data wrapped in a data field. But handling errors by checking an errors field feels un-RESTful and causes opposition.
Maybe we could provide an alternative, non-standard mechanism for error reporting to ease acceptance by RESTful thinkers?
My first idea subject to discussion is this: if the client request has an Accept header application/graphql.data+json, then the response body is only the data without the wrapping; or the list or errors, if it's not empty. This makes partial results impossible, of course. Validation errors would result in a 400 status; other errors in a 500; we may define a mechanism to specify the status code for an exception, e.g. a @Status annotation similar to the @ErrorCode annotation already defined in SmallRye GraphQL.