5 ms·
That’s why we can’t have nice things.
by nesarkvechnep 3y ago
That’s why we can’t have nice things.
- teaearlgraycold 3y agoI and many others have done it for years. HTTP codes were not designed for the web in 2023. They were for the 90s.
- dragonwriter 3y agoNothing has changed which would invalidate the basic model, though. “It’s old” isn’t a reason to throw out a working design.
- teaearlgraycold 3y agoNo, the reason is "It was built for a time when people expected the web to mostly be a series of interconnected static documents"
- dragonwriter 3y agoThat still doesn’t explain any actual problem, it explains what you think is the cause behind the unspecified problem, jumping right over the key question.
- teaearlgraycold 3y agoBasically, HTTP is the envelope. Ethernet > IP > TCP > HTTP > My application HTTP is a hyper text transfer protocol, designed as such. My application is a RPC front-end for a series of data stores, AI models, etc. Using HTTP codes for your application's protocol is a mismatch. There are some fairly general-purpose HTTP error codes that can meet many application's use cases, but the overlap is not perfect. You can get greater granularity by ignoring it entirely. Going HTTP 200-only means any non-200 is now definitively from 3rd party middleware, a router, proxy, etc. The boolean check of "did I hit my application code?" is easy and useful.
- dragonwriter 3y agoIts easy and useful if you just return details in response bodies, which you can do with errors as well as 200s, and that lets everything else (including client code) that deals with your responses (which doesn’t generally care if it hit your application code as likely as it cares about the things HTTP error codes communicate) handle errors without having to code for your bespoke method of error reporting.