bananoidandroid
Of course there is. Maybe in your line of work and set of “standard” tools there is no distinction, and everything is a world of simple rules. For me, handling an error based on a response is what you are supposed to do. If you do not differ between them, you’ll just spend time to figure it out by hand.
I get it. I’m just trying to illustrate why i like to differ between com and app errors. Now we have identified three different scenarios, all returning 404. Resource not found Data not found (client error). Data not found (server error). when we could treat them different because their nature is fundamentally different. I mean if we request a list of objects and nothing was found, because we asked for a date when there was no data, its not an error. But i suppose many still just throw around exceptions still instead of handle them properly, and it looks terrible in the log. Imo if i know the reason for a behaviour its not necessarily an error, and using an error code for a non-error makes it harder to find real errors. Maybe i’ve just been turned off by how they have been used in our legacy code. Maybe you don’t define 404 as a client side and not an error, and i guess thats fine. But its pretty counterintuitive to be a number in a list of client errors and be anyrhing but.
The customer expects a row to exist. The server does not find it.
The customer sent a valid request, and it should exist according to the customer.
The server could not find it. It can find others, but not that one, so from the server perspective it’s the client that gave the wrong id. If i always send a 404, the customer system think it did something wrong, which it didnt. Should they try to find the error on their side now, as it is a “client error”?
If i send a 500 every time, the customer will think the server is at fault, which it is. The server just could not find that row. What if the customer actually made an error, sending the wrong id, and i send the same code every time. It will be the servers fault every time the customer makes an error, and now they will never double check their inputs.
My point is, there is no nuance with these old codes. Obviously i will send a 500 for a caught exception and a 400 for a client error, but it is not always so easy.
I mean sure, in the strict meaning of the code-guides you are probably correct. Most problems stems for us at least from cross-reference issues which are normally configuration problems in the underlying system or other data-related issues. Those are often not neither the responsibility of the server or the client, and sometimes its both. There are often no code that is suitable to respond, and to just send “Bad request” when it’s a good request - does not make sense. Therefore i think it’s better to let badrequest be for bad requests, instead tell the client that sure, this is a good request but for this reason it didn’t work this time. This has to happen for it to work. Either i can do it with a simple structure in json with maybe 5 status codes and a message, or i have to figure out what 20 http status codes both i and the client has to implement and give them meaning that isn’t their intended meaning.
Obviously you can, and i do returm 4xx codes if the initial parsing, authentication or something else goes wrong im the controller, but once im in the next api, or any number of systems down the chain, im probably gonna return a 200 with a status with a tracking code. It’s proven, at least for us very helpful to find issues fast on both sides. To me getting a 4xx back when it’s step 6 our of 13 that is the problem in the API but the request itself is fine doesn’t seem meaningful and just makes customers assume things. I guess if every endpoint only does one thing, i’d probably do like you.
The parser in most APIs will automatically handle parsing responses for 400 errors, but if the logic fails due to data being wrong, what do you respond with? E.g you send a valid SSN but the database could not find the person, or you send a valid email, but bo such email was found.
Honestly makes perfect sense.
- Message received and successfully parsed.
- 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.
Ah, a fellow camelot unchained sponsor? It’s coming any day now. Any day i tell ya!
While passing on american products in general is a good thing, not all products are equal. Signal is far better for privacy than anything in europe currently. Until there is a good option, supporting an open source non-profit company won’t give the US any profits from your usage. And that’s what really counts. To be honest, signal is the only safe system currently. What makes it unsafe is proprietary software on the clients it’s being used on like IOS or whatever android branch it’s used on.
We really should have something, especially as privacy in europe is really in danger with the chatcontrol agenda. We need both an operating system, and safe communication made in europe, and even more importantly, EU legislation that prevents things like chatcontrol even to be considered.