8 ms·

The HTTP protocol is a lost art. These days people don't even look at the status code and expect some mumbo jumbo JSON payload explaining the error.

by jannes 2y ago

AznHisoka 2y ago
I dont look at the code because its wrong sometimes. Some pages return a 200 yet display an error in the page
- DaSHacka 2y ago
  Nothing more annoying than a 200 response when the server 'successfully' serves a 404 page
  - CodesInChaos 2y ago
    Returning a 3xx redirect to an generic error page is even worse than 200.
klntsky 2y ago
I would argue that HTTP statuses are a bad design decision, because they are intended to be consumed by apps, but are not app-specific. They are effectively a part of every API automatically without considerations whether they are needed. People often implement error handling using constructs like regexp matching on status codes, while with domain-specified errors it would be obvious what exactly is the range of possible errors. Moreover, when people do implement domain errors, they just have to write more code to handle two nested levels of branching.
- marcosdumay 2y ago
  > because they are intended to be consumed by apps, but are not app-specific Well, good luck designing any standard app-independent protocol that works and doesn't do that. And yes, you must handle two nested levels of branching. That's how it works. The only improvement possible to make it clearer is having codes for API specific errors... what 400 and 500 aren't exactly. But then, that doesn't gain you much.
- throw0101b 2y ago
  > I would argue that HTTP statuses are a bad design decision, because they are intended to be consumed by apps, but are not app-specific. Perhaps put the app-specific part in the body of the reply. In the RFC they give a human specific reply to (presumably) be displayed in the browser: HTTP/1.1 429 Too Many Requests Content-Type: text/html Retry-After: 3600 <html> <head> <title>Too Many Requests</title> </head> <body> <h1>Too Many Requests</h1> <p>I only allow 50 requests per hour to this Web site per logged in user. Try again soon.</p> </body> </html> * https://datatracker.ietf.org/doc/html/rfc6585#section-4 https://datatracker.ietf.org/doc/html/rfc6585#section-4 * https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429 But if the URL is specific to an API, you can document that you will/may give further debugging details (in text, JSON, XML, whatever).
- est 2y ago
  > error handling using constructs like regexp matching on status codes Oh the horror. I would assume the practice is encourage by "RESTful" people?
KomoD 2y ago
That's because a lot of people refuse to use status codes properly, like just using 200 everywhere.
- kstrauser 2y ago
  A colleague who should’ve known better argued that a 404 response to an API call was confusing because we were, in fact, successfully returning a response to the client. We had a long talk about that afterward.
  - Joker_vD 2y ago
    No, it is pretty confusing: the difference between 404 from hitting an endpoint that the server doesn't serve (because you forgot to expose this endpoint, oops!) and a 404 that means "we've successfully performed the search in our DB for the business entity you've requested and guarantee you that it does not exist" is rather difficult to tell programmatically.
    - yjftsjthsd-h 2y ago
      I'm open to arguing about which error to return in each case, but surely we can agree that neither of those warrant a 200?
      - echoangle 2y ago
        Why not? I wouldn’t say „I performed the search and there’s 0 results“ is an error condition. It’s just the result of a search, and everything went fine.
        yjftsjthsd-h 2y ago
        Hm, maybe? I guess it depends on what we mean by search; if myapp.com/search?someproduct finds that there are 0 matches then yeah that's probably a 200, but if myapp.com/products/123456 fails because no product has id 123456 then that's a textbook 404.
deleted 2y ago
[deleted]

The HTTP protocol is a lost art. These days people don't even look at the status code and expect some mumbo jumbo JSON payload explaining the error.

by jannes 2y ago

The HTTP protocol is a lost art. These days people don't even look at the status code and expect some mumbo jumbo JSON payload explaining the error.

AznHisoka 2y ago

I dont look at the code because its wrong sometimes. Some pages return a 200 yet display an error in the page

DaSHacka 2y ago
Nothing more annoying than a 200 response when the server 'successfully' serves a 404 page
- CodesInChaos 2y ago
  Returning a 3xx redirect to an generic error page is even worse than 200.

klntsky 2y ago

I would argue that HTTP statuses are a bad design decision, because they are intended to be consumed by apps, but are not app-specific. They are effectively a part of every API automatically without considerations whether they are needed. People often implement error handling using constructs like regexp matching on status codes, while with domain-specified errors it would be obvious what exactly is the range of possible errors. Moreover, when people do implement domain errors, they just have to write more code to handle two nested levels of branching.

marcosdumay 2y ago
> because they are intended to be consumed by apps, but are not app-specific Well, good luck designing any standard app-independent protocol that works and doesn't do that. And yes, you must handle two nested levels of branching. That's how it works. The only improvement possible to make it clearer is having codes for API specific errors... what 400 and 500 aren't exactly. But then, that doesn't gain you much.
throw0101b 2y ago
> I would argue that HTTP statuses are a bad design decision, because they are intended to be consumed by apps, but are not app-specific. Perhaps put the app-specific part in the body of the reply. In the RFC they give a human specific reply to (presumably) be displayed in the browser: HTTP/1.1 429 Too Many Requests Content-Type: text/html Retry-After: 3600 <html> <head> <title>Too Many Requests</title> </head> <body> <h1>Too Many Requests</h1> <p>I only allow 50 requests per hour to this Web site per logged in user. Try again soon.</p> </body> </html> * https://datatracker.ietf.org/doc/html/rfc6585#section-4 https://datatracker.ietf.org/doc/html/rfc6585#section-4 * https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429 But if the URL is specific to an API, you can document that you will/may give further debugging details (in text, JSON, XML, whatever).
est 2y ago
> error handling using constructs like regexp matching on status codes Oh the horror. I would assume the practice is encourage by "RESTful" people?

KomoD 2y ago

That's because a lot of people refuse to use status codes properly, like just using 200 everywhere.

kstrauser 2y ago
A colleague who should’ve known better argued that a 404 response to an API call was confusing because we were, in fact, successfully returning a response to the client. We had a long talk about that afterward.
- Joker_vD 2y ago
  No, it is pretty confusing: the difference between 404 from hitting an endpoint that the server doesn't serve (because you forgot to expose this endpoint, oops!) and a 404 that means "we've successfully performed the search in our DB for the business entity you've requested and guarantee you that it does not exist" is rather difficult to tell programmatically.
  - yjftsjthsd-h 2y ago
    I'm open to arguing about which error to return in each case, but surely we can agree that neither of those warrant a 200?
    - echoangle 2y ago
      Why not? I wouldn’t say „I performed the search and there’s 0 results“ is an error condition. It’s just the result of a search, and everything went fine.
      - yjftsjthsd-h 2y ago
        Hm, maybe? I guess it depends on what we mean by search; if myapp.com/search?someproduct finds that there are 0 matches then yeah that's probably a 200, but if myapp.com/products/123456 fails because no product has id 123456 then that's a textbook 404.

deleted 2y ago

[deleted]