5 ms·

I find their rationale curious. Rather than attempting to have some level of standardization, they are denying any standardization because: - You should send so

I find their rationale curious. Rather than attempting to have some level of standardization, they are denying any standardization because: - You should send something to stderr (why not both?) - Choice is ambiguous (and so something non-standard will be better?)

masklinn 5y ago
> Choice is ambiguous (and so something non-standard will be better?) It would say it's certainly better to say nothing than to imply a scheme is some sort of standard when it's really a largely unusable not-at-all a standard. Every time I try to use them, sysexits feels like a strictly less usable and relevant version of HTTP categories 400 and 500 smashed together with no rhyme or reason.
- nerdponx 5y ago
  Personally I'd rather have a somewhat arbitrary standard than no standard at all!
  - 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).

masklinn 5y ago

> Choice is ambiguous (and so something non-standard will be better?) It would say it's certainly better to say nothing than to imply a scheme is some sort of standard when it's really a largely unusable not-at-all a standard. Every time I try to use them, sysexits feels like a strictly less usable and relevant version of HTTP categories 400 and 500 smashed together with no rhyme or reason.

nerdponx 5y ago
Personally I'd rather have a somewhat arbitrary standard than no standard at all!
- 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).