4 ms·

Nothing prevents you from setting both a non-2xx API header, and still making the difference of "invalid path" vs "entity doesn't exists" clear in the response

by dtech 4y ago

Nothing prevents you from setting both a non-2xx API header, and still making the difference of "invalid path" vs "entity doesn't exists" clear in the response body.

ehnto 4y ago
In regards to interoperability it does matter I think, if it's non-standard then it won't "just work" in an application that's expecting the standard. Practically though, APIs are a wild west, and almost no-one implements status codes right. So the idea of standardized interoperability was out the window a long time ago.
- jstrong 4y ago
  in that vein: status is pretty useful, seems like a good solution is using two separate non-200 status codes to differentiate between employee not found vs typical 404 no such endpoint/url/path.
  - dtech 4y ago
    unfortunately HTTP doesn't have good status codes to make the distinction
- eadmund 4y ago
  > In regards to interoperability it does matter I think, if it's non-standard then it won't "just work" in an application that's expecting the standard. The standard is to return a 404 for a resource that is not found. The standard is not to return a 200. An application which expects a 200 for a not-found resource is not expecting standard behaviour, and is dead wrong.
  - ehnto 4y ago
    I never suggested anyone send or expect a 200 for a resource not found, I suggested following the standards, so we're in agreeance.
- jerf 4y ago
  "Practically though, APIs are a wild west, and almost no-one implements status codes right." This is the conclusion I've come to. What the RFCs say the status codes mean doesn't matter anymore. There isn't anywhere near enough consensus on what they mean or how to treat them to base a system off of in the abstract. What can specifically matter is how systems in the concrete will react to them. Do you have something that needs to be CDN'd? Then you'd better return status codes that make that work. Is it going to be proxied? Then you'd better return status codes that make that work. Is it never going to be either of those things and only directly accessed by internal users? Then use status codes in a way that works for them. Do you have a monitoring system? Use status codes in a way that works for those systems. Do you have conflicting requirements as a result of those things? Bummer. Sucks to be you. Best get to figuring out what to do about that, but one thing I can tell you is that carefully consulting the RFCs about what status codes "mean" won't be much of a help in such a situation. Maybe a little. But not much. To the extent you want to reply with a "but what about...", I said, if it works, use it. While it is the wild west, there are certainly some patterns. 200 vs. "a non 200" response certainly has patterns of meaning to it, and if playing into those patterns works for you, great! Do it. But if I encounter a case where it doesn't, I cry precisely zero tears and do what does work. The time to moralistic and prissy about what status codes "really mean", if it ever really existed (to be honest, all there really ever was was "return one of the 5 or 6 codes the browsers understand when appropriate, and the search engines will follow the broswers"), is long gone. You can be wistful about how nice it could theoretically be if we just all agreed on what they all mean, but that's just not going to happen in a world where I can barely get people to agree that numbers shouldn't be strings in JSON, let alone precise details about what exactly a hundred error codes mean across such a diversity of systems and users. I could even argue they are a failed element of the protocol. Such an argument would center around the futility of trying to represent such a rich variety of possibilities, along with such a rapidly changing variety of possibilities, into a single number. It's hopeless. You can't enumerate all the possible successes and failures of such a broad protocol like this, and it didn't help to try. It's just another instance of the "shared ontologies are fundamentally unscalable" problem.
  - ehnto 4y ago
    I think there are some standards fans whipping out the downvotes, but I think jerf and I are both very aware that this is not how it SHOULD be. But it is how it is. I built an API scraper years ago now, and I gave up, APIs are not standardized, they're not consistent. I dreamed of an interoperable library of APIs you could pipe around to create new applications. It's too much work to manage all the differences in how people have built their APIs. But as jerf pointed out, there can be myriad reasons standards end up playing second fiddle.

by dtech 4y ago

Nothing prevents you from setting both a non-2xx API header, and still making the difference of "invalid path" vs "entity doesn't exists" clear in the response body.

ehnto 4y ago

In regards to interoperability it does matter I think, if it's non-standard then it won't "just work" in an application that's expecting the standard. Practically though, APIs are a wild west, and almost no-one implements status codes right. So the idea of standardized interoperability was out the window a long time ago.

jstrong 4y ago
in that vein: status is pretty useful, seems like a good solution is using two separate non-200 status codes to differentiate between employee not found vs typical 404 no such endpoint/url/path.
- dtech 4y ago
  unfortunately HTTP doesn't have good status codes to make the distinction
eadmund 4y ago
> In regards to interoperability it does matter I think, if it's non-standard then it won't "just work" in an application that's expecting the standard. The standard is to return a 404 for a resource that is not found. The standard is not to return a 200. An application which expects a 200 for a not-found resource is not expecting standard behaviour, and is dead wrong.
- ehnto 4y ago
  I never suggested anyone send or expect a 200 for a resource not found, I suggested following the standards, so we're in agreeance.
jerf 4y ago
"Practically though, APIs are a wild west, and almost no-one implements status codes right." This is the conclusion I've come to. What the RFCs say the status codes mean doesn't matter anymore. There isn't anywhere near enough consensus on what they mean or how to treat them to base a system off of in the abstract. What can specifically matter is how systems in the concrete will react to them. Do you have something that needs to be CDN'd? Then you'd better return status codes that make that work. Is it going to be proxied? Then you'd better return status codes that make that work. Is it never going to be either of those things and only directly accessed by internal users? Then use status codes in a way that works for them. Do you have a monitoring system? Use status codes in a way that works for those systems. Do you have conflicting requirements as a result of those things? Bummer. Sucks to be you. Best get to figuring out what to do about that, but one thing I can tell you is that carefully consulting the RFCs about what status codes "mean" won't be much of a help in such a situation. Maybe a little. But not much. To the extent you want to reply with a "but what about...", I said, if it works, use it. While it is the wild west, there are certainly some patterns. 200 vs. "a non 200" response certainly has patterns of meaning to it, and if playing into those patterns works for you, great! Do it. But if I encounter a case where it doesn't, I cry precisely zero tears and do what does work. The time to moralistic and prissy about what status codes "really mean", if it ever really existed (to be honest, all there really ever was was "return one of the 5 or 6 codes the browsers understand when appropriate, and the search engines will follow the broswers"), is long gone. You can be wistful about how nice it could theoretically be if we just all agreed on what they all mean, but that's just not going to happen in a world where I can barely get people to agree that numbers shouldn't be strings in JSON, let alone precise details about what exactly a hundred error codes mean across such a diversity of systems and users. I could even argue they are a failed element of the protocol. Such an argument would center around the futility of trying to represent such a rich variety of possibilities, along with such a rapidly changing variety of possibilities, into a single number. It's hopeless. You can't enumerate all the possible successes and failures of such a broad protocol like this, and it didn't help to try. It's just another instance of the "shared ontologies are fundamentally unscalable" problem.
- ehnto 4y ago
  I think there are some standards fans whipping out the downvotes, but I think jerf and I are both very aware that this is not how it SHOULD be. But it is how it is. I built an API scraper years ago now, and I gave up, APIs are not standardized, they're not consistent. I dreamed of an interoperable library of APIs you could pipe around to create new applications. It's too much work to manage all the differences in how people have built their APIs. But as jerf pointed out, there can be myriad reasons standards end up playing second fiddle.