Hacker News Reader

Comment by tshaddox | Hacker News Reader

I read the part about not using 404s twice and I still don’t quite get it. It sounds like the author was using some infrastructure separate from their actual app server that unpredictably returned 404 responses and thus they don’t want to deliberately return 404 responses?

View on HN

They are attempting to argue that 404 is ambiguous, so we should avoid it. They do not to my eyes meaningfully highlight a replacement outside of some very specific cases.

I strongly disagree with this stance as I don't think 404 is ambiguous at all. Although it would be useful to know at what point in the broader hierarchy of a specific resource requested the unavailability starts: Ultimately 404 just means the specific 'tip of the spear' resource requested is not found.

The thing about 404, is that you can both return 404 as well as an error document that has the structure the author is looking for, which means there is no reason why you can't return a 404 status.

Got 404, returned body is json, returned body is an error object, good to go.

Oh and, by returning a 404 you help intermediate caches know that they should not cache the response.

without 404, how will I force my collection of funny 404 images onto the world: https://tenor.com/view/dog-moon-moonlanding-landing-nasa-gif...

Not the author, but I think the idea is to avoid overloading the meaning of 404. They argue 404 should mean the request didn't match a known route, in case the request is recognized but the record itself isn't found you should return a different 4xx code

I kind of get this and wouldn't complain about an API doing this, but I also wouldn't be surprised for `/api/v1/posts/abc-123` to return 404 because the route handler couldn't match the post ID.

Some infrastructure like that might exist on the server end; load balancers, etc.

I took it to mean 404 should mean you haven't hit the API at all.

Reply on news.ycombinator.com