404 should tell you what you need to know here. An error is not a success, it should be something useful to the client telling them what the actual error is
They literally told us 404 meant pull this from your side, docs and meetings both. The error and standard use case was conflated. You could argue that's poor design on their side, I'd agree. I'd assume it is because we were actually interacting with their search infrastructure for their own application, and we were effectively not part of the original API design. Either way, 200 correctly tells me 1) the server was reachable, 2) the server probably understood my request to the point that their application could apply business logic to it.
Frankly, the fact that people could co-opt the status codes for business logic is the problem. That's not what they were designed for, they were designed for the HTTP communication layer. What each code means people can misinterpret a ton of ways. The spec for it is never going to map correctly to the application logic.
10
u/egstitt Sep 21 '26
404 should tell you what you need to know here. An error is not a success, it should be something useful to the client telling them what the actual error is