| > Semantically, it's an error that the frontend can handle No it isn't. Semantically `200 OK` means a request was successful. That isn't me saying that, that's the RFC: https://datatracker.ietf.org/doc/html/rfc1945#section-9.2 The semantically correct message to signal to the frontend that the error originated on its side, and thus has to be fixed by it, is a 4xx response, period. https://datatracker.ietf.org/doc/html/rfc1945#section-9.4 > Many people treat HTTP error codes as exceptions / real infrastructure problems. Doesn't change the fact that they aren't exceptional. A != 2xx response code is not an exceptional occurrence. As soon as I talk to a networked process, especially one that I don't control, I am talking to unreliability, and being able to deal with that is normal program operation, not an exception. > I mean, we build rich clients. You can't simply auth with a user/password header when you get a 401/403 and your browser shows an alert. It's not 2003 anymore. So? What exactly does the auth method I'm using have to do with the server using semantically correct return codes? Luckily, I also consume a lot of good APIs in my code. Guess what they send back when my client messes up something during OAuth. Hint: It's not `HTTP/200 OK` |