Please, never ever again add such features to standards as a joke. Some backend folks have started to return it as an indetermiante error code, which in turn means that all client-side libraries will have to handle it at some level.
They have to handle it anyway. There's nothing in the HTTP specifications that disallows a server from using whatever codes it wants to that aren't specifically specified. There is no "HTTP 527 Server Needs a Nap" but it is perfectly legal for my server to reply to clients with that HTTP status, and clients are expected to handle it like they would handle any other non-specific error in the 5xx class of response codes (server error).
Other perfectly legal responses:
242 - TOO MUCH COFFEE
(Server is overcaffeinated and processing requests too quickly)
299 - SUCCESSFUL BUT SASSY
(Request succeeded but the server is throwing shade about it)
333 - QUANTUM UNCERTAINTY
(The server simultaneously succeeded and failed until observed)
Clients have always had to handle unknown return code according to the first digit, and by and large they do this succesfully, with the exception of 1xx codes which are widely buggy.
Imo, the real problem and where it went wrong is the people using it as an error code outside of its intended purpose(to signal being a teapot, not a coffee machine). I mean this 100% seriously, unironically.
I thought that at first, but then realized that it is, in fact, correctly a client error: the client erroneously directed a coffee-related request to a server that is, in fact, not meant to service such requests. :-P
I counter-disagree. It is so easy in life to have fun. There's so much fun everywhere. If you're so starved for fun then this won't do it for you either. The higher the scale the more likely your easter egg becomes not an easter egg.
I also think the supermajority of engineers prefer fun entirely outside of work, hence why open source can feel so lonely and without corporate funding would probably shrink to a pathetic size. Hence why personal websites are so culturally irrelevant. Or why there's such a lack of artistic experimentation in apps or web. Or why there's so few non-corporate meetups nowadays in CA or NY.
Oh, definitely hard disagree with this! I am an engineer because I love it and because it brings me joy, and I love love LOVE things that involve humor and fun within the realm of what is oftentimes just work. It delights me when people can find ways to be creative and tongue-in-cheek and not take things so seriously all the time. It is one way in which we can have fun in our work. For me, the idea of keeping all my fun separated from my work sounds like a dystopian nightmare!
So many things in the IT world started as non-professional things by non-professional engineers. If you're a professional who lives off one of these things you should be glad that someone wanted to have fun at some point.
"I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already."
Counter-counter-disagree. This is the ultimate way to make sure the joke is preserved for the future generations while keeping implications absolutely miniscule.
Thankfully, error codes such as this are structured so that the initial "4" digit is the only one that really matters. Just treat it as a client error and you can't go wrong.
Well, I recently used it in a small PostgREST-subset query builder I wrote in case the query builder received an input more complicated that what it could handle. I found 418 a natural response in this case. In retrospect a 5xx (edit: or better 422) error is more appropriate, however.
So, you're saying you expect libraries that don't have a generic 4xx "Oops, my bad, dev please handle it" error case to be bothered by the existence of 418 in any way, shape or form? I think you're barking up the wrong tree.
