| Ok, I see now what is the point that we disagree: What does 200 means with regards to existence/non-existence. I think 200 means something exists and 404 is the representation of non-existence. You think (please correct me if I am wrong) that the existence or non-existence information should be in the body. Actually I think the underlying (and more important point) is about how valuable the existence/non-existence information is for the client => how quick the client should have feedback about this? I think existence is a very important information and thus should be a first class citizen of the data representation. Thus I want it in the status code on the same level with the body itself. If you put it in the body then that means for me an extra step to parse the body and then see what is there. So then the existence/non-existence is on the second level. In your case with responding with 200 + body then the 200 status becomes irrelevant and I always need to parse the body => time is lost to access the _first_ important information that should then guard my business logic to parse or not the body. While in my case (using 200 and 404 status) the client receiving 404 knows directly (without any parsing of the body) that the request was not successful in retrieving existing data. |
But that's not what the spec says:
>200 OK - The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:
> GET an entity corresponding to the requested resource is sent in the response;
>The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.
404 is not the representation of non-existence. It's the representation of not found. Something can be "not found" for many more reasons than non-existence. Which ultimately causes the person integrating your API much consternation because they have no idea if it's a "Everything worked" 404 or "My DNS is borked" 404 or "Your server's routing is borked" 404 or half a dozen other possibilities. Sure, you might add further information to your 404 response but that means you can't have generic 404=bad monitoring. Plus causes headaches for people that are working in systems that do assume 404=bad.
200 means that the request has succeeded. And in these cases it has. You requested a representation of employee 100 and you're getting one (it doesn't exist).
Even if you disagree with the word smithing the latter is far far easier to work with.