kogasa

Status 200 for errors is common for non-REST HTTP APIs. An application error isn't an HTTP error, the request and response were both handled successfully.

There may be a need for additional information, there just isn't any in these responses. Using a basic JSON schema like the Problem Details RFC provides a standard way to add that information if necessary. Error codes are also often too general to have an application specific meaning. For example, is a "400 bad request" response caused by a malformed payload, a syntactically valid but semantically invalid payload, or what? Hence you put some data in the response body.

I'm speaking my truth. XR Adderall, crack em open and pour em on me tongue. The caviar of stimulants

My only time-release capsule is filled with little beads, I just pop it open and eat the beads like pop rocks

I've been taking 6+ pills a day for years and still can't get myself to swallow them. I just chew everything. Tasty painkillers and caffeine.

This should be done with font ligatures, not replacing character combinations with other characters that can't be typed normally

I'm stuck on the homological algebra exercise

Once every 50 years or so

If my cooking senses are right, it would be like cooking bacon in a stainless steel pan, which is sticky and burny but not impossible

Don't think it saves bandwidth unless it's a DNS level block, which IT should also do but separately from uBO

No, it isn't

You're making assumptions about the control flow in a hypothetical piece of code...