Alternative error reporting

[t1]

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.

[t1]

This combines nicely with #342

[phillip-kruger]

This will be outside the scope of the GraphQL Spec ? -1 from me. @andymc12 what is your thoughts ?

[andymc12]

Yes, I tend to agree with @phillip-kruger - I think the MP GraphQL spec should stick to GraphQL semantics as much as possible (obviously using common patterns from well-known APIs like JAX-RS where appropriate). In this case, I think the idea has merit, but it is probably not conceptually close enough the expected GraphQL behavior to include in the spec. But a MP GraphQL implementation product like SmallRye or SPQR could certainly support this idea without violating the MP GraphQL spec. HTH