3 ms·

It's not that it's arbitrary, it's that 1. it isn't univerally adopted, and 2. those that try to adhere to it don't have the same understanding about which thin

by derefr 5y ago

It's not that it's arbitrary, it's that 1. it isn't univerally adopted, and 2. those that try to adhere to it don't have the same understanding about which things qualify for which categories. sysexit(3) defines a contract that calling programs would find useful to rely upon — to do different things when programs exit with different particular values. But because of these human factors, calling programs cannot rely on it. There's no signal in the noise. The contract is not enforced. This goes from just useless to actively harmful, because the process of 1. finding the sysexit code standard, 2. thinking you can rely on it; 3. writing a program that does rely on it; 4. finding out that in practice its contract is rarely obeyed; and 5. ripping that code back out of your program — all takes time and human labor. The existence of this "standard" thus creates net-negative utility. It consumes people's time to no useful end.

OJFord 5y ago
Like HTTP statuses then? I'd still rather have them than not. (And I'll still be annoyed by GraphQL saying 200 OK - here're your errors!)
- Quekid5 5y ago
  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).
- nerdponx 5y ago
  I learned about this recently and have never been more disgusted with a software design decision. Why??
  - OJFord 5y ago
    It makes sense in a 'technically true but ugh' sort of way. The GQL server is saying it successfully executed that query, here is the response, it happens to contain an error. And in further fairness, I believe there can be multiple 'responses' within, some of which may be errors and others not. But still ugh, personally I'd rather have resource-oriented semantic HTTP (read: 'REST' without triggering empassioned debate) just for that. I don't think adds enough over HTTP to warrant this sort of weirdness (sibling comment describes it as the next layer) - if it were just an HTTP alternative sitting on TCP fine, and I'm sure it would happily not have a top-level status code (or a more meaningful one) itself anyway.
    - derefr 5y ago
      > and I'm sure it would happily not have a top-level status code (or a more meaningful one) itself anyway Fun thing to learn about: WebDAV introduced the HTTP 207 "Multi-Status" response status, for precisely the case where the response is actually a multi-response envelope. https://httpstatuses.com/207 https://httpstatuses.com/207 I often feel that the extra methods and features introduced by WebDAV would be usefully generalized to other analogous use-cases, like GraphQL. But then I recall that most of the WebDAV-specific stuff specifies XML-based request/response message formats, and quickly give up on the idea of any modern programmer doing it as a cool hack. Can't have "cool hack" and "XML" in the same sentence, after all ;)
nerdponx 5y ago
How is that contract any different from the set of supported CLI flags or an API? Obviously you can't assume that any particular command line tool follows any particular standard. But that's no reason to not write programs that follow a standard! If you don't document how to use your program, that's another problem and the nobody will be able to use it anyway.

by derefr 5y ago

OJFord 5y ago

Like HTTP statuses then? I'd still rather have them than not. (And I'll still be annoyed by GraphQL saying 200 OK - here're your errors!)

Quekid5 5y ago
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).
nerdponx 5y ago
I learned about this recently and have never been more disgusted with a software design decision. Why??
- OJFord 5y ago
  It makes sense in a 'technically true but ugh' sort of way. The GQL server is saying it successfully executed that query, here is the response, it happens to contain an error. And in further fairness, I believe there can be multiple 'responses' within, some of which may be errors and others not. But still ugh, personally I'd rather have resource-oriented semantic HTTP (read: 'REST' without triggering empassioned debate) just for that. I don't think adds enough over HTTP to warrant this sort of weirdness (sibling comment describes it as the next layer) - if it were just an HTTP alternative sitting on TCP fine, and I'm sure it would happily not have a top-level status code (or a more meaningful one) itself anyway.
  - derefr 5y ago
    > and I'm sure it would happily not have a top-level status code (or a more meaningful one) itself anyway Fun thing to learn about: WebDAV introduced the HTTP 207 "Multi-Status" response status, for precisely the case where the response is actually a multi-response envelope. https://httpstatuses.com/207 https://httpstatuses.com/207 I often feel that the extra methods and features introduced by WebDAV would be usefully generalized to other analogous use-cases, like GraphQL. But then I recall that most of the WebDAV-specific stuff specifies XML-based request/response message formats, and quickly give up on the idea of any modern programmer doing it as a cool hack. Can't have "cool hack" and "XML" in the same sentence, after all ;)

nerdponx 5y ago

How is that contract any different from the set of supported CLI flags or an API? Obviously you can't assume that any particular command line tool follows any particular standard. But that's no reason to not write programs that follow a standard! If you don't document how to use your program, that's another problem and the nobody will be able to use it anyway.