Hacker News Reader

Comment by motogpjimbo | Hacker News Reader

That's the purpose of an error message isn't it? I'm not sure what an HTTP response code is adding to that.

In my experience, in any situation where you produce an API where you want the client to pay close attention to the actual error that occurred, the list of official HTTP response codes is generally woefully inadequate for the task and you're going to want to work with something much more specific.

If my payment processor is telling me they're declining a transaction because the customer failed a fraud check, I'd rather they didn't communicate that to me with some random 4xx code one of their devs found on a Wikipedia article and tried to bend into shape. Rather, I'd hope the importance of the situation would lead them to compile a table of custom error codes that I can implement properly in my program's logic.

View on HN

Let me get this straight, you don't think codes matter, but you want to manage a giant proptietary list of codes?

Won't you just send up in those huge discussions you waste so much time on?

To continue the payment processor example, if there are 10 different reasons for declining a transaction, how do you propose mapping those onto 4xx codes? Would you just choose 10 at random? Or would you just return, e.g., E_INSUFFICIENT_FUNDS?

I'm not sure anyone would propose you randomly map different 4xx codes to a bunch of different internal server errors. For the one example you provided I would probably use a 500 code, return the relevant message and call it a day. In that case you might also return an additional code if you have some extremely complex logic for handling that error at the client side, but in that case your client might be a little too complicated.

That doesn't mean I wouldn't also use the best practices codes for authentication vs authorization etc. I say this loosely though because best practices are really just that. It's more important to maintain a level of consistency within your team or organization so you're all speaking the same language. It's nice to have a starting point like rest APIs (or something that resembles them) so you're not writing a completely new rulebook on standard stuff that other people have already figured out, you can focus more on the problems your team is trying to solve. Why not use a 409 when there's a conflict? Someone already solved that problem. You can still return whatever pretty error message you want.

FWIW, my policy is that 5xx codes are always bugs, or an infrastructure-level failure/refusal to serve.

4xx codes are processing errors, or application-level refusals.

I end up borrowing 422 from WebDAV for a generic "Unprocessable Entity", with an error code (for API interpretation/reference lookup) and description (for user display, when appropriate) in the response body.

Yeah that's understandable when frameworks default everything to 500, that's often true, I just couldn't think of a more appropriate code to the specific example apparently there actually is a code for fraudulent payments so 402 code would be good.

re: best practices. I inherited an API that always responds with 200s, even when there's an error condition. When a document can't be found it returns a 200 OK with a response body "NOT_FOUND".

By ignoring existing standards and re-inventing the wheel with custom errors the previous development team made the system harder to maintain & harder to onboard.

I've also encountered that, it's very frustrating when you get a 200 ok, then you continue on in your client but there was actually an error expressed in the body of the 200 response. Ah gee.

Reply on news.ycombinator.com