I'm developing a web API and aiming for consistency with status codes across my projects. I've run into a debate about the proper use of the 404 error code. My supervisor believes that a 404 should only be returned when a URL is not found, like visiting example.com/users and getting nothing. However, I think that when a valid request is made with an ID (like example.com/users/1) and there's no data in the database, we should return a 404 since the requested resource isn't found. I'd love to hear different perspectives from real developers on this! Thanks!
5 Answers
You’re not alone! Many developers face this dilemma. The general consensus is that if the resource isn’t found, use 404. It simplifies client-side error handling, which is crucial in API development.
You’re spot on! In REST APIs, returning a 404 when a resource isn’t found is standard practice. If the ID is valid but no record exists, a 404 is the right code. Check out any REST specification for confirmation!
I get both points, but I lean towards your view. Returning a 200 along with a message can lead to misunderstandings. Status codes are meant to convey specific outcomes, and 404 serves that purpose well here.
I see where your supervisor is coming from, but if the resource isn’t there, 404 is the way to go. It maintains clarity for users of the API, who will rely on those status codes for error handling, rather than assuming everything went smoothly with a 200.
Your intuition is correct. If the endpoint works but the resource doesn’t exist, it should return a 404. Clients expect this behavior, and it aids in debugging. Returning a 200 could lead to confusion since it implies success, which isn't the case here.
Exactly! Clear status codes help developers understand what's happening without having to dive deep into the messages.
Totally agree! It's all about using the correct HTTP status codes, right?