[lordalch]

I'm personally of the opinion that 418 shouldn't be considered a joke response, but would actually useful as 418 "Unsupported Device".

What response should a printer give if you asked it to send a fax, but you have a base-model printer that doesn't support sending faxes. From the perspective of the printer, I know what you want (i.e. not a 404) and you've asked for it correctly (i.e. not 400 or 401 or 403), but I can't do it, and this does not indicate an error on my part (not a 500 or 503). Thus, 418: Unsupported Device.

Perhaps this too much of an overlap with 404 (I don't have that resource) and 501 (I can't do that verb to that resource), which I assume is why there's not a huge need for it. But if we're going to have 418 exist and receive browser support anyway, it might as well have a useful meaning rather than just exist as a joke.

This interpretation is fully in keeping with the non-joke meaning of the original RFC, as a teapot is a device that does not support brewing coffee.

[jlund-molfese]

I'd probably use a 422 in that case. I think 422 errors are underused, and can good for communicating errors when a client requests something which doesn't make sense from a business context.

[hnarn]

For those that haven't memorized every single HTTP error code, 422 is "Unprocessable Entity": 'the server understands the content type of the request entity, and the syntax of the request entity is correct, but it was unable to process the contained instructions.'

[Nashooo]

It's complete overlap with 404 IMO

[hnarn]

If you throw a 404 to a completely valid GET for a file that doesn't exist for example, how is that a "complete overlap" to something like asking a database REST API to print a PDF? In the latter case, you have the ability to give a more detailed (better) error message, so why shouldn't you?