Comment by teaearlgraycold

I feel similarly about HTTP. The protocol maps really well to resource stores (stuff like S3). GET, PUT, DELETE all make sense. HTTP status codes are built exactly for this use case as well. But as web developers we're mostly not developing resource stores. Those are highly generic and can be built once and used by millions of apps. Most of the time someone is writing code that interacts with HTTP they are performing RPC. You can go for GraphQL, gRPC, or many other RPC systems that just shirk the whole thing. They make everything use a POST to a single endpoint and add another layer of abstraction so you don't need to return a 4XX/5XX error for some highly application-specific situation.

It's clear the RFC writers got a little out of hand. "402 Payment Required", "407 Proxy Authentication Required", "508 Loop Detected" look to me like attempts to work in functionality specific to certain types of apps or deployments. Why do these RFC authors get their specific needs implemented into the bedrock of the web and then expect me to find where my needs happen to overlap and then tuck every aspect specific to my app into "400 Bad Request" or "500 Internal Server Error"? Every time I see a web app actually utilize more than the bare minimum of HTTP status codes I roll my eyes. Put that shit into the application layer. The protocol wasn't made for you. It was made for LAMP-stack apps serving mostly static assets.