HTTP 200 {"status": "success", "payload": "{\"error\": true}"}Ah, the 200 Go Fuck Yourself pattern.
I use HTTP error codes in my API, and still occasionally see a GET /resource/{“error”:“invalid branchID provided”} from people who don’t seem to know what they are.
I know an architect who designs APIs this way. Also includes a status code in the response object because why have one status code when you can have two, potentially contradictory, status codes?
I may have run in your acquaintance work, stuff along the lines of
200 OK{ error_code: s23, error_msg: "An error was encountered when performing the operation" }If you happen to run into him, kindly tackle him in the groin for me.
Thanks!
Well, looking at your example, I think a good case can even be made for it.
“s23” doesn’t look like an HTTP status code, so including it can make total sense. After all, there’s plenty of reasons why you could want custom error codes that don’t really align with HTTP codes, and customised error messages are also a sensible use case for that.
Of course duplicating the actual HTTP status code in your body is just silly. And if you use custom error codes, it often still makes sense to use the closest matching HTTP status code in addition to it (so yeah, I agree the 200 in your example doesn’t make a lot of sense). But neither of those preclude good reasons for custom codes.
Still, 200 should not be returned. If you have your own codes, just return 500 alongside that custom code.
I inherited a project where it was essentially impossible to get anything other than 200 OK. Trying to use a private endpoint without logging in? 200 OK unauthorized. Sent gibberish instead of actual request body format? 200 OK bad request. Database connection down? You get the point…
It’s the HTTP version of “great job.”
Computer version of dude wincing through the pain, tears in eyes, giving you a thumbs up.
You get the point…
Lmao do they work at Oracle???
I’ve seen the status code in a JSON response before: https://cloud.google.com/storage/docs/json_api/v1/status-codes#401-unauthorized
One reason I can think of for including it is that it may make it easier for the consumer to check the status code if it’s in the JSON. Depending on how many layers of abstraction you have, your app may not have access to the raw HTTP response.
Although, yeah you lose the single source of truth though.
Depending on how many layers of abstraction you have, your app may not have access to the raw HTTP response.
That sounds like either over-abstraction or bad abstraction then
And no error message…
I guess that’s how it’s done. Yeah.
This became a religious war at my last role.
At a prior job, our
APIload balancers would swallow all errors and return an HTTP 200 response with no content. It was because we had one or two clients with shitty integrations that couldn’t handle anything but 200. Of course, they brought in enough money that we couldn’t ever force them to fix it on their end.I once worked on a project where the main function would run the entire code in a try-catch block. The catch block did nothing. Just returned 200 OK. Didn’t even log the error anywhere. Never seen anything so incredibly frustrating to work on.
You can put anything in your dialog box
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.
This is basically the difference between HTTP 4xx and 5xx error codes. 4xx means the client did something wrong (invalid request, tried to load something that doesn’t exist, doesn’t have access), whereas 5xx means the request was OK but something broke on the server.
Yeah, I know how http status codes work. I just followed the existing pattern at my current place with gRPC and this post made me realize I don’t know most gRPC error codes and best practices.
The way you phrased it made it sound like you definitely don’t
gRPC does not use HTTP status codes. I meant that I might be making a similar mistake with gRPC status codes though, after checking just now, not so much (there are only 17 total codes, not all of which apply to my APIs).
Welcome to graphQL. The REST abstraction few need, but everyone wants for some reason.
Here I am preferring 200, with success boolean / message string…
Iike HTTP errors codes for real fuck up’s, if I see 500 somethings fucked in the app, otherwise a standardised json response body seems way easier
What about both? User supplies bad input? HTTP 400 with response body json describing the error in a standard format?
deleted by creator
That’s not what HTTP errors are about, HTTP is a high level application protocol and its errors are supposed to be around access to resources, the underlying QUIC or TCP will handle most lower level networking nuances.
Also, 5xx errors are not about incorrect inputs, that’s 4xx.
…HTTP is a high level application protocol and its errors are supposed to be around access to resources…
I’ve had fellow developers fight me on this point, in much the same way as your parent post.
“If you return a 404 for a record not found, how will I know I have the right endpoint?”
You’ll know you have the right endpoint because I advertised it—in Open API, in docs, etc.
“But, if
/users/123returns a 404, does that mean that the endpoint can’t be found or the record can’t be found?”Doesn’t matter. That resource doesn’t exist. So, act appropriately.
It’s not like you can’t return a body with the 404 that specifies that the user itself is not found versus the ending being wrong.
Standardize a response body across your APIs that specifies the cause of the non-2xx response. Have an enum per API/service for causes. Include them in the API doc.
If anyone still doesn’t get it, quietly dispose of them at your friend’s pig farm.
deleted by creator
You can send 4xx errors yourself too. If the client needs to change something about the request, that’s a 4xx, like 400 Bad Request. If the server has an error and it’s not the client’s fault, that’s a 5xx like 502 Bad Gateway.
The wikipedia listing of all HTTP codes is quite helpful. People also forget you can send a custom response body with a 4xx or 5xx error. So you can still make a custom JSON error message.
deleted by creator
A 2xx means success to its requester. If you have an error in step 6 out of 13 that breaks the resource action, you shouldn’t be returning a success.
You might argue what to return and what kind of information to include in the response (like tracking numbers), but it shouldn’t be a 2xx and I don’t see how a misleading 200 would be more helpful than a 400 bad request.
deleted by creator
and to just send “Bad request” when it’s a good request - does not make sense
That’s when you use a 5xx status, then. The client doesn’t care how many other services you reach out to in order to fulfill their request. A 5xx code also covers failures in other parts of the system.
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: truemeans 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.
