Hacker News new | ask | show | jobs
by klntsky 537 days 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.
3 comments
throw0101b 537 days 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://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).

link
marcosdumay 537 days 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.

link
est 536 days ago
> error handling using constructs like regexp matching on status codes

Oh the horror. I would assume the practice is encourage by "RESTful" people?

link