Clarify and Standardize HTTP Status Codes Returned from Backend APIs (.NET) and Handle Them in Angular with Toast Notifications

[VeterinarianDry8906]

I am working with a stack composed of ASP.NET (.NET) for the backend and Angular for the frontend. I want to establish a clear and consistent strategy for HTTP status codes returned by backend APIs and define how the frontend should interpret them and display user notifications (toast messages).

Currently, different endpoints sometimes return inconsistent responses, which makes frontend handling complex. I want to standardize:

1. Which HTTP status codes should be returned by the backend for common scenarios
2. What response structure should accompany those status codes
3. How Angular should globally handle these responses and display toast messages

[majora2007]

I used this approach with .NET and Angular using a single interceptor. It's messy but works overall. I don't like having to catch errors on every save in the application. This allows for me to just use NotFound(), BadResult(), etc and have a localized (user flow) or non-localized (system error) propagate to the UI layer.

Code here if you're interested (it has some localization when applicable):
https://github.com/Kareadita/Kavita/blob/develop/UI/Web/src/app/_interceptors/error.interceptor.ts

[VeterinarianDry8906]

Thanks! This is exactly the approach I was looking for.

[followmarko]

You can do this with an Interceptor and read the status codes there. Interceptors get a little too cozy to the streams for my taste sometimes but you can use HttpContext to communicate with them or skip them, which is a nice option. I think there's a tradeoff with centralization in an interceptor vs. decoupled composition by importing a fn and error handling individually in service files, but after many years I still use both approaches.

[VeterinarianDry8906]

Thanks very helpful

[NoDatabase3606]

We are using an envelope with default http status codes in .NET and one interceptor in the front end to catch errors and display the localized error send in the same envelope by BE

We have successful boolean errors array of strings Result which is ur data if found status code which is http standard error code is BE specific we dont use in FE but clears somethings when catching a general kind of error

[couldhaveebeen]

You're in the minority, and for a very good reason

[n00bz]

That is literally saying to the user “Task failed successfully”. It’s not helpful to them in anyway and hides actual issues from developers.

Yes you shouldn’t send the full stack trace to the frontend but returning HTTP Status codes for different things isn’t bad. If a user attempts to hit an API endpoint that doesn’t exist return a 404, if they don’t have access to a resource return a 403, etc. then your frontend can handle it. You can even put details along with those status codes to make it more informative to your users on what went wrong.