I actually use the 418 code in a simple API we use for IOT devices. I wrote a small program that runs on Raspberry Pis that checks a HTTP endpoint and turns power on and off to a room depending on whether the room is booked out. I wanted a status code on the API that could only possibly be generated on purpose, so if it receives a 418 response it knows to turn off the power; any other response, failure etc turns the power on (so we don't have a room out of use if it breaks).<p>Also it's fun :)
Why is 418 the particular target? Just because of RFC2324?<p>> IANA should also typographically distinguish “Unassigned” and “Reserved” in the registry descriptions, to prevent confusion.<p>This I can get onboard with. Honestly, I've never seen a 418 easter egg, but I'd think it would be an HTTP spec violation if it didn't at least conform to the higher level 4xx definition (Client Error) :)
Many API developers misuse/overload HTTP status codes when they should actually be using application specific status codes delivered via a wrapper to the response.<p>Any time an API returns a correct response the HTTP response code should be 2xx. Many developers use 4xx status codes to indicate things like data validation errors or other things that are not part of the HTTP transport.<p>HTTP is the transport layer, and any application specific scenarios are best handled with a custom error namespace that can be returned within any 2xx HTTP response.<p>Generally speaking, if the HTTP layer is returning 5xx you have a server problem and client code should not know anything about that or do anything but retry. If the HTTP layer is returning 4xx then the client is likely poorly designed or misconfigured.<p>But for typical client operation, when there is no server error or client design/configuration error, HTTP responses should be 2xx or 3xx and any additional detail should be handled in an application-specific way, not by overloading the meaning of HTTP response codes, which are for transport-related concerns only.
We can never fix the "Referer" header, and we have accepted it! So, why not accept 418 for what it is ? Let it at-least complete its 20th year.<p>HTTP/1.1 418 I'm a Teapot
Yeah, I'm sorry, but now we need to standardize BREW HTTP verb.<p><a href="https://tools.ietf.org/html/rfc2324" rel="nofollow">https://tools.ietf.org/html/rfc2324</a>
I'm somewhat interested in spec writing and legal matters. It seem to me, that this rfc is overly verbose given the change it proposes. And (I think, correct me if I'm wrong) rfc:s are generally supposed to be as short as possible.<p>For example, "IANA should also typographically distinguish “Unassigned” and “Reserved” in the registry descriptions, to prevent confusion." seem like a good idea but is an unrelated matter.