Comment by jawns | Hacker News Reader

Comment by jawns | Hacker News Reader

Regarding the author's recommendation against using 404:

The author says it's ambiguous, because it could mean the route is not found, or it could mean the requested item is not found.

Some people use 204 to indicate the latter:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204

It basically means, "We received and understood your request, but you're not getting a response." And you can infer that it's because the content you requested is not there.

At a previous company, we returned a 200 for anything that was not a true HTTP error on our side, with a dedicated error message in the response for anything else. So, for instance, instead of returning a 403 when the API user provided invalid data, we would return a 200, indicating that we successfully did everything we were supposed to do, but then explained in the response what invalid data needed to be corrected.

I liked that approach. Anything non-200-level meant that we screwed up. And any 200-level response with an error message meant that the user screwed up.

> At a previous company, we returned a 200 for anything that was not a true HTTP error on our side

I work at a company that does this and it is beyond annoying. We've had multiple discussions between the dev team and we chalk it up the difference between application developers, who want the error codes to reflect the state of the application, and network engineers, who want the error codes to reflect the state of the network. Both sides have merit, but as an app developer I really hate the networking engineer approach to this.

If it worked for you, that's fine... but this is completely counter to how most HTTP applications work and definitely not a best practice. Both returning errors or the interpretation of the meaning of 204.

The author at least suggests using 400, which at the very least will make clients and proxies behave in a predictable way, but ideally you just return the appropriate HTTP status code, and use a well-defined response body to indicate why the specific error was returned.

I like very much something I saw in the Dropbox API:

All application errors are returned with a 409 code, and then you are sure to have a properly json formatted error in the body that can will have an error code more relevant for your case.

So that could be NOT_FOUND in such a case.

Have you not heard of 500 errors? How about 400 for "bad request"?

Seriously, stop reinventing what is already an established standard. There is nothing more annoying than a server that returns a 200-class status when the thing I requested is not in the response.

But HTTP 204 is also appropriate for a some POST requests where a response is unnecessary or sometimes not even possible (e.g. browser-based "beacon" requests during onunload[1]), so if you use 204 to represent entity-does-not-exist then you need to re-think how to handle no-response-responses.

As an alternative to using HTTP 404 for detecting a misconfigured server with bad routing, you could use the "Server" response header to include an invariant indicator as a confidence sign to the client that the HTTP 404 response does not mean bad-routing or misconfigured server - or expired-domain-name-now-points-to-a-domain-squatting-website.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Navigator/s...

Reply on news.ycombinator.com