I was not strictly referencing the OSI model here, despite using terminology that conflates it. In my comment, I am using "application" to refer to the thing that the HTTP protocol is transporting. Example: Making a payment with the PayPal API. PayPal is the application, interfaced with HTTP. If I want to return an error code that an account was banned, I am arguing we should not be returning esoteric HTTP error codes but stick to basic ones and send the PayPal-specific error codes as payload.
Here's a real-world example with Linux.
eclipse ~ # route add 29834
SIOCADDRT: No such device
In the above example, the developer is trying to retrofit one of Linux's standard error messages to one that best fits the condition this application has encountered. Do you think that error message makes any sense to the user? I don't.
Let's try another one:
eclipse ~ # route del 1234
SIOCDELRT: No such process
Choosing to use Linux's errno.h here instead of a custom message is kind of like choosing to use using HTTP's status codes to get your application's problem explained to the user, even though there might not be an HTTP-level code that specifically fits the problem description. Maybe 402 Payment Required works for payments, but what about something else? What if you need to first do action x before doing action y, should we have HTTP error 469 DoXBeforeY? That's what I was trying to explain.
Wikipedia's page on the OSI model references this as "application-entity" and "application":
When identifying communication partners, the application layer determines the identity and availability of communication partners for an application with data to transmit. The most important distinction in the application layer is the distinction between the application-entity and the application. For example, a reservation website might have two application-entities: one using HTTP to communicate with its users, and one for a remote database protocol to record reservations. Neither of these protocols have anything to do with reservations. That logic is in the application itself. The application layer has no means to determine the availability of resources in the network. [0]
Maybe a casual user doesn't care, but a power user / dev trying to script it would benefit. Just like how some users of Linux applications just use them interactively and read the English language stderr stream, while others appreciate a myriad of exit codes so a calling script can unambiguously do different things depending on what sort of problem the application is presenting.
Well, the exit codes of both of those commands (despite being different) is actually 7. But 7 does not match either error string, so the power user would have to string search it anyway.
eclipse ~ # route add 1234
SIOCADDRT: No such device
eclipse ~ # echo $?
7
eclipse ~ # route del 1234
SIOCDELRT: No such process
eclipse ~ # echo $?
7
Maybe I used a bad example? I get your point though.
