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.

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.

Its formally considered a flawed democracy. I do the same thing with my kids. If i want them to clean their room i’ll just ask them “do you want to clean your room, or you want to do the dishes and take out the trash?” and they’ll always go for cleaning their room because it feels like they are getting something out of the deal, it’s less “nasty” and they have a sense of choice but realistically i win in both scenarios.

I’ve been there twice, first time during 2008 and the security was crazy. Had homeland security already doing background check in the airport at the checkin counter, and while there i had two “VIP” searches due to connecting flights. Next time was just a few months ago, was scared they’d do some nasty searches and checks again but this time it was far more pleasant, signed a form on the internet, although it cost a bit, everything went smootly. I was suprised that the traveling was like going to all other places. The people are great, the food is great and really an overall great experience.

I will NOT set my foot there again as long as Trump is in power and really, i was scared to say anything on the internet before going because he’d already won the election which is quite telling but since biden was still running things i felt safe taking my electronics. Now i doubt they’ll ever let me back in 😂

Thanks! I initially considered going the wildcard route until i saw the workload involved for my host! There does seem to exist autorenewal programs for the largest hosts out there but i’m trying to support my local businesses so it’s unfortunately out of of my scope at the moment, but i’ll checkout your suggestion and see what tailscale has to offer!

I’ve set up a reverse proxy to try out hosting a few APIs but i’m curious about best practice and haven’t found any good way to do it. Anyway, i have them running dotnet 9 on debian, and hosting them on http ports and then reverse proxying to apache that serves them externally with certbot on 443 to some real hostnames. I would really want to host them on https internally as well, but is there a neat way to “cert” them without an internal CA-service? My experience with self-signed certs are mostly that they always force me to trust the server cert in my connection strings, which is also unsafe so i just don’t bother. Is it worth working on and which is the best approach here?