4 ms·
Boy. This is the best explanation of this belief I've come across yet. It's coherent and reasonable, even if I disagree. My highest scoring StackOverflow answe
by cpfohl 4y ago
Boy. This is the best explanation of this belief I've come across yet. It's coherent and reasonable, even if I disagree.
My highest scoring StackOverflow answer [1] (and my most controversial) is on exactly this topic and _no one_ in any competing answer have given _any_ sensible explanation of their reasoning. I've genuinely never understood their thought process, despite trying really, *really* hard. This explains it a bit, even though I totally disagree.
There are other tools for helping differentiate different varieties of 404 or 401. There are status codes, there's _nothing_ preventing you from returning a payload with explanation or overriding the Reason Phrase. If your HTTP client is too fragile to handle a very common usage pattern for HTTP status codes then pick a different one.
---
[1] - https://stackoverflow.com/questions/11746894/what-is-the-proper-rest-response-code-for-a-valid-request-but-an-empty-data/11760249#11760249 https://stackoverflow.com/questions/11746894/what-is-the-pro...
- stackbutterflow 4y agoReading this discussion on hn and stackoverflow, I feel sometimes software development is more philosophy than engineering.
- NateEag 4y agoYes, software dev absolutely is closer to philosophy than engineering. There is such a thing as software engineering, but that isn't what most of us do (nor is it what we should be doing, IMO). NASA needs software engineers. Low-level critical systems need them, so the G-MAFIA has a few. For most business purposes, though, the iterative exploratory "let's get a UI out there and see how it works" is exactly what we need. It's a useful, cost-effective strategy when lives aren't on the line, and it isn't engineering. (My current job title is "Software Alchemist")
- dncornholio 4y agoOnly if you let it. Developers tend to overthin things. Be careful on where you spend you energy on. Because honestly the answer is, as long as you are consistent, it really doesn't matter if you use status codes or not.
- matsemann 4y agoWow, 452 upvotes and 89 downvotes on your answer. Very controversial, indeed! While I agree with you, I sometimes misuse 200 OK even for actual errors. Most times because whatever internal library I've used to do the requests have made it hard to parse the error data if it happens (just throws a general exception instead when it encounters a 4XX or 5XX). Or sometimes because the request failing is somewhat expected, but the client library then insists on doing lots of error handling when it fails (logging, alarms, circuit breakers and whatnot), polluting everything.
- that_james 4y agoI appreciate the kind words, thank you. I've said it in other responses, but maybe I should have been specific that I was referring to HTTP RPC (explicitly not citing REST for a reason). Perhaps a combination of both is best, but in my experience a nice clean break between these 2 layers at the protocol level helps clients simplify their handling of responses. 2xx: Go ahead and parse (another commenter pointed out Content-Type. That one always gets me) 4xx/5xx: Something bad happened and the request wasn't processed by the server, either because it blew up (5xx) or because you did something _very_ wrong (4xx) The objective is clarity to the caller. It's a little obtuse but I think it works well with that objective in mind.
- nrdvana 4y agoIf it's not REST then shouldn't the url be /api/v1/employees?id=1000 instead of encoding the employee id in the URL? In this case the path is the endpoint, so a employee id is a parameter and not a controller action.
- dragonwriter 4y ago> If it’s not REST then shouldn’t the url be /api/v1/employees?id=1000 instead of encoding the employee id in the URL? The query portion of a URL is, in fact, part of the URL, so that is encoding the employee id in the URL, and REST doesn’t care about how URLs are constructed, in the first place (in fact, excessive concerns about out-of-band knowledge about how URLs are constructed mostly are a sign of not doing HATEOAS, in contravention of the REST architectural style.)
- nrdvana 4y agoYes I used the wrong word. I meant "instead of encoding the employee id in the path?" And instead of "if its not rest" I meant (in the context of the article) "if it's HTTP RPC" because the author clarified that they were talking about RPC rather than REST. Remote Procedure Calls typically identify "endpoints" such that a specification of the endpoints could be compiled into a host language's function-calls. The logical way to do that with HTTP is to have a path be the function, and HTTP parameters (whether url or posted) be the parameters of the function. Using a URL that has both a resource ID encoded in the path and also query parameters is a mixture of REST and RPC. Since the example given in the article does not show parameters, I think it is reasonable to call it REST, as many other commenters here have inferred. The author claiming it is RPC doesn't jive with my expectations for RPC. Maybe I'm just complaining about calling it RPC. If it's neither RPC nor REST then it's just some random mismash of HTTP-ish stuff, and I don't think that's a particularly strong argument for "things should be done like this".
- okamiueru 4y agoI really enjoyed that SO thread, and your answer. In my opinion your take is correct, to the extent that it is fascinating that it is a controversial topic. The majority of people, (and by people, likely limited to software developers), seem to not fully understand HTTP status codes. This is of course fine, the fascinating part is the extent they insist they do. Whenever the majority, in any technically field, opine something different, I assume they are right, and I've missed something. But having designed APIs for years, I can safely say that it doesn't apply here.
- okamiueru 4y agoAlso, the OP article does explain well what could cause this misunderstanding. HTTP resource nouns shouldn't ever be "guessed". The resource either exist or it doesn't. And if it exists, it either has a data, or it doesn't. 404: it doesn't exist 204: it exists and has no data to parse.