ASP.NET REST APIs with Custom Error Models
Hi all. I'm currently developing a REST API and have a few questions regarding error flow, as well as custom error models. I'd appreciate an answer to any or all of these questions, if possible!
1) There is a guide out there for error handling in REST APIs, https://docs.microsoft.com/en-us/aspnet/core/web-api/handle-errors?view=aspnetcore-6.0, that seems to heavily imply the current paradigm seems to involve entirely exception-based patterns, versus returning (ex.)
BadRequest()
, NotFound()
, etc. Is this really the right way to do things now?
2) If the answer to 1) is "no": Are custom error models considered an acceptable practice? The same guide linked above uses an error handle that formats errors as an RFC 7807
(?) JSON object. In the past, I have used custom error models and simply returned that object to describe the error code and problem(s)/error(s). Are either types of error models preferred over the other?
3) If custom models are considered an OK practice: How do I avoid redundantly specifying the HttpStatusCode that is set/returned in my error response? Previously, my error returns in my controller methods would look something like this:
This is redundant because I'm returning NotFound(), which already sets the HttpStatusCode to 404. However, I can't think of a feasible way to set ErrorModel's HttpStatusCode property without this redundant (helper) static method. Is there a best practice for this as well? For example, somehow accessing the currently set HttpStatusCode to set the model's code dynamically?3 Replies
i use FluentResults and a middleware that translates the FluentResults to ActionResults to communicate http status codes
https://discord.com/channels/143867839282020352/156079822454390784/964620871174078514 small code snippet from the action filter I have implemented, doesn't contain everything to make it useful. Then within my code I can do stuff like
looks neat, but...seems incredibly overengineered for something as simple as what I'm doing (at the moment - just a single controller). I'll check it out either way. Is the middleware you mentioned completely custom or is it a package I install alongside FluentResults?