3 ms·

At least HTTP status codes can reasonably point to where the error is: 2xx - Fine, you get to decide what to do 4xx - Problem on your end, mate 5xx -

At least HTTP status codes can reasonably point to where the error is: 2xx - Fine, you get to decide what to do 4xx - Problem on your end, mate 5xx - Problem on our end. Sorry, mate 3xx - It's complicated... GraphQL responding 200 to erroneous queries is... surprising (assuming only HTTP semantics), but what kind of errors were these? Of course, we're assuming servers implemented by at least semi-reasonable people. EDIT: That said, I'd actually be happy with a protocol-level 2, 4, 5, 3 and leaving the rest up the application layer. I know that isn't very HATEOAS, but in practice all people truly want is RPC. (Sadly.)

derefr 5y ago
> GraphQL responding 200 to erroneous queries is... surprising To me, both GraphQL (and also JSON-RPC, another weird one for HTTP errors) are really application-layer protocols of their own that are just "spoken over" HTTP, and as such implement their own error signalling standards. In cases like that, an HTTP error doesn't pertain to anything being discussed "inside" the overlay protocol; but instead refers to the carrier protocol. For example, seeing an HTTP 404 in response to hitting a GraphQL or JSON-RPC endpoint, wouldn't mean that the resource you asked for with your overlay-protocol request doesn't exist, but rather that the endpoint you wanted to speak the overlay protocol to doesn't exist. Consider, by analogy: a websocket, which actually does speak a formal HTTP sub-protocol. If you make the right request, you get your HTTP connection upgraded into a WebSocket connection. If you don't? Carrier protocol error.
- masklinn 5y ago
  Indeed, both GraphQL and JSON-RPC use HTTP as a simple pipe: * JSON-RPC has no dependency on HTTP, you can use it over regular sockets or websocket (that's exactly what the Chrome DevTools Protocol does). That is why JSON-RPC has a concept of "request ids", similar to protocols like IMAP: it was designed for compatibility with full-duplex communications and asynchronous results (rather than strict request/response). * GraphQL's semantics are not strictly fitting within HTTP, what with being able to send multiple queries in the same request (which is a different proposition than sending concurrent requests, even when pipelining, when it comes to server resources).

derefr 5y ago

> GraphQL responding 200 to erroneous queries is... surprising To me, both GraphQL (and also JSON-RPC, another weird one for HTTP errors) are really application-layer protocols of their own that are just "spoken over" HTTP, and as such implement their own error signalling standards. In cases like that, an HTTP error doesn't pertain to anything being discussed "inside" the overlay protocol; but instead refers to the carrier protocol. For example, seeing an HTTP 404 in response to hitting a GraphQL or JSON-RPC endpoint, wouldn't mean that the resource you asked for with your overlay-protocol request doesn't exist, but rather that the endpoint you wanted to speak the overlay protocol to doesn't exist. Consider, by analogy: a websocket, which actually does speak a formal HTTP sub-protocol. If you make the right request, you get your HTTP connection upgraded into a WebSocket connection. If you don't? Carrier protocol error.

masklinn 5y ago
Indeed, both GraphQL and JSON-RPC use HTTP as a simple pipe: * JSON-RPC has no dependency on HTTP, you can use it over regular sockets or websocket (that's exactly what the Chrome DevTools Protocol does). That is why JSON-RPC has a concept of "request ids", similar to protocols like IMAP: it was designed for compatibility with full-duplex communications and asynchronous results (rather than strict request/response). * GraphQL's semantics are not strictly fitting within HTTP, what with being able to send multiple queries in the same request (which is a different proposition than sending concurrent requests, even when pipelining, when it comes to server resources).