I’m working on a REST API and I’m confused about when to use 404 status codes. Everyone says you should return 404 when a resource doesn’t exist, but this seems confusing to me.
The problem is that 404 usually means the URL itself is wrong. So when I get a 404, I don’t know if it means the endpoint is invalid or if the specific item just doesn’t exist in the database.
Let’s say I have this endpoint:
http://example.com/api/customer/25
If this returns 404, does it mean customer 25 doesn’t exist in my system? Or does it mean I should have used a different URL like:
http://example.com/v1/api/customer/25
Right now I just send back empty data with a 200 status when the customer doesn’t exist. This feels clearer to me even though it might not follow REST standards. What’s the right approach here?
you’ve got it a bit wrong. a 404 means the resource is just not there, so if customer/25 is missing, that’s the right status. invalid endpoints or methods are diff. scenarios, and returning 200 with no data can be misleading. just stick with 404 for non-existent stuff.
Yeah, this confusion is super common when you’re starting with REST APIs. Here’s what clicked for me: HTTP status codes have different jobs. If customer 25 doesn’t exist in your database, 404 is the right call - that resource isn’t found at that URI. But if someone hits a bad endpoint or wrong API version? That’s a different 404 (usually from your web server before your app even sees it) or maybe a 400 Bad Request if your routing catches wonky paths. The trick is good API docs that spell out what endpoints exist. Then clients can tell the difference between ‘valid endpoint, missing resource’ vs ‘you hit the wrong URL entirely.’ Don’t return 200 with empty data - it breaks HTTP rules and makes error handling a nightmare for clients.
Think about it from the client’s perspective. When I hit /api/customer/25 and get a 404, I know exactly what happened. If I’m following your API docs correctly, that 404 tells me customer 25 doesn’t exist - simple as that. Not sure about the URL format? Test with a resource you know exists first. Returning 200 with empty data just creates headaches. You’re saying the request worked when it didn’t, forcing clients to dig through response bodies to figure out what’s actually there. Most REST clients expect 404 for missing resources - that’s the standard. Break that convention and you’ll mess up how developers handle errors.