<p><pre><code>    &quot;the existing status codes are much too general for a modern website&#x2F;API... why worry about spending any time on a redundant, not-as-useful HTTP status code?

    When pressed for a reason why it is important to use specific status codes, a common reason cited is that HTTP is a layered system and that any proxy, cache, or HTTP library sitting between the client and server will work better when the response code is meaningful. I don’t find this argument compelling, if for no other reason than this: in a world where everyone is moving to HTTPS, we’ve forbidden any proxy or caching nodes that are not under direct control of the server.&quot;
</code></pre>
I do find this reasoning to be perfectly valid and have implemented many APIs accordingly for quite some time.  It has a lot to do with the first place to look when something goes wrong.  Does the 404 mean I mistyped the URL or that the Application can&#x27;t find the Resource?  Did the endpoint crash or did I mess up the rewrite in the nginx config?<p>That said, Michael&#x27;s counter-argument is well worth consideration.  I&#x27;ve generally left HTTP status codes and Application status codes completely separate for any sizable project, but I find this article and argument worthwhile and will continue to reconsider, as I generally do upon every new project, whether using HTTP status codes to represent general application state is worthwhile.<p>The original point regarding complexity is most important to me, but Michael&#x27;s diagrams do an excellent job of showing how Application state can be considered an extension of the Protocol in specific cases.