Programmer Humor

Honestly makes perfect sense.

1. Message received and successfully parsed.
2. An error occured while processing request. Ideally they would have a message in the response saying what went wrong if it is relevant for the user.

The problem with only reacting with 500 Internal Server Error is that the user will never improve their input data, if they can do something about it. Responding with 404 is just mean as they wont know if the endpoint is not found or the database couldn't find any data. Differentiating the communication from the processing is i.m.o the best way to do it.

me with gRPC error codes: nil, parameter error, app error -- OK, you fucked up, we fucked up. Edit: forgot NotFound.

I really should read about the various ones that exist at some point, but I've always got bigger fires to put out.

Edit, since it seems unclear, gRPC != HTTP and does not use the same status codes. I meant that I felt like I was using fewer than I should, though I just checked and basically not.

You can put anything in your dialog box

This is a good practice tho. The HTTP code describes the status of the HTTP operation. Did the server handle it? No? Was the url not found? Did it time out? Was the payload too large? And the JSON describes the result of the backend operation. So 200 OK with error: true means that your HTTP request was all good, but the actual operation bugged out for whatever reason. If you try to indicate errors in the backend with a HTTP error code, you quickly get confused about which codes can happen for what reason.