La mejor práctica para devolver errores en ASP.NET Web API

Me preocupa la forma en que devolvemos los errores al cliente.

¿Devolvemos el error inmediatamente lanzando HttpResponseException cuando recibimos un error?

public void Post(Customer customer) { if (string.IsNullOrEmpty(customer.Name)) { throw new HttpResponseException("Customer Name cannot be empty", HttpStatusCode.BadRequest) } if (customer.Accounts.Count == 0) { throw new HttpResponseException("Customer does not have any account", HttpStatusCode.BadRequest) } } 

O acumulamos todos los errores y luego los enviamos al cliente:

 public void Post(Customer customer) { List errors = new List(); if (string.IsNullOrEmpty(customer.Name)) { errors.Add("Customer Name cannot be empty"); } if (customer.Accounts.Count == 0) { errors.Add("Customer does not have any account"); } var responseMessage = new HttpResponseMessage<List>(errors, HttpStatusCode.BadRequest); throw new HttpResponseException(responseMessage); } 

Este es solo un código de muestra, no importa ni los errores de validación ni el error del servidor, solo me gustaría conocer las mejores prácticas, los pros y los contras de cada enfoque.

En mi caso, generalmente HttpResponseException una HttpResponseException y establezco el código de estado de acuerdo con la excepción lanzada y, si la excepción es fatal o no, determinaré si envío la HttpResponseException inmediatamente.

Al final del día, es una API que envía respuestas y no vistas, por lo que creo que está bien enviar de vuelta un mensaje con la excepción y el código de estado al consumidor. Actualmente no he necesitado acumular errores y devolverlos, ya que la mayoría de las excepciones se deben a parámetros o llamadas incorrectas, etc.

Un ejemplo en mi aplicación es que a veces el cliente solicitará datos, pero no hay datos disponibles, así que lanzo una excepción noDataAvailable personalizada y la dejo burbujear a la aplicación de API web, donde luego en mi filtro personalizado que lo captura enviando una copia relevante mensaje junto con el código de estado correcto.

No estoy 100% seguro de cuál es la mejor práctica para esto, pero esto está funcionando para mí actualmente, así que eso es lo que estoy haciendo.

Actualización :

Desde que contesté esta pregunta, se han escrito algunas publicaciones de blog sobre el tema:

http://weblogs.asp.net/fredriknormen/archive/2012/06/11/asp-net-web-api-exception-handling.aspx

(este tiene algunas características nuevas en las comstackciones nocturnas) http://blogs.msdn.com/b/youssefm/archive/2012/06/28/error-handling-in-asp-net-webapi.aspx

Actualización 2

Actualización a nuestro proceso de manejo de errores, tenemos dos casos:

  1. Para errores generales como no encontrado, o parámetros inválidos que se pasan a una acción, devolvemos una HttpResponseException para detener el procesamiento de inmediato. Además de los errores de modelo en nuestras acciones, entregaremos el diccionario de estado modelo a la extensión Request.CreateErrorResponse y lo envolveremos en una HttpResponseException. Al agregar el diccionario de estado modelo, se obtiene una lista de los errores del modelo enviados en el cuerpo de la respuesta.

  2. Para errores que ocurren en capas superiores, errores del servidor, dejamos que la excepción salte a la aplicación Web API, aquí tenemos un filtro de excepción global que mira la excepción, lo registra con elmah y trata de darle sentido a la configuración del http correcto código de estado y un mensaje de error amigable relevante como el cuerpo nuevamente en una HttpResponseException. Para las excepciones que no esperamos, el cliente recibirá el error predeterminado de 500 servidores internos, pero un mensaje genérico debido a razones de seguridad.

Actualización 3

Recientemente, después de recoger la API web 2, para enviar errores generales, ahora utilizamos la interfaz IHttpActionResult , específicamente las clases incorporadas en el espacio de nombres System.Web.Http.Results como NotFound, BadRequest cuando encajan, si no lo hacen extenderlos, por ejemplo, un resultado no encontrado con un mensaje de respuesta:

 public class NotFoundWithMessageResult : IHttpActionResult { private string message; public NotFoundWithMessageResult(string message) { this.message = message; } public Task ExecuteAsync(CancellationToken cancellationToken) { var response = new HttpResponseMessage(HttpStatusCode.NotFound); response.Content = new StringContent(message); return Task.FromResult(response); } } 

ASP.NET Web API 2 realmente lo simplificó. Por ejemplo, el siguiente código:

 public HttpResponseMessage GetProduct(int id) { Product item = repository.Get(id); if (item == null) { var message = string.Format("Product with id = {0} not found", id); HttpError err = new HttpError(message); return Request.CreateResponse(HttpStatusCode.NotFound, err); } else { return Request.CreateResponse(HttpStatusCode.OK, item); } } 

devuelve el siguiente contenido al navegador cuando el artículo no se encuentra:

 HTTP/1.1 404 Not Found Content-Type: application/json; charset=utf-8 Date: Thu, 09 Aug 2012 23:27:18 GMT Content-Length: 51 { "Message": "Product with id = 12 not found" } 

Sugerencia: No ejecute HTTP Error 500 a menos que haya un error catastrófico (por ejemplo, Excepción de fallas WCF). Elija un código de estado HTTP apropiado que represente el estado de sus datos. (Consulte el enlace de la vacuna a continuación).

Campo de golf:

  • Manejo de excepciones en ASP.NET Web API (asp.net) y
  • Diseño de API RESTful: ¿qué pasa con los errores? (apigee.com)

Parece que tiene más problemas con la Validación que los errores / excepciones, por lo que le diré un poco sobre ambos.

Validación

Las acciones del controlador generalmente deben tomar modelos de entrada donde la validación se declara directamente en el modelo.

 public class Customer { [Require] public string Name { get; set; } } 

Luego puede usar un ActionFilter que envía automáticamente mensajes de validación al cliente.

 public class ValidationActionFilter : ActionFilterAttribute { public override void OnActionExecuting(HttpActionContext actionContext) { var modelState = actionContext.ModelState; if (!modelState.IsValid) { actionContext.Response = actionContext.Request .CreateErrorResponse(HttpStatusCode.BadRequest, modelState); } } } 

Para obtener más información sobre este cheque, visite http://ben.onfabrik.com/posts/automatic-modelstate-validation-in-aspnet-mvc

Manejo de errores

Lo mejor es devolverle un mensaje al cliente que representa la excepción que ocurrió (con el código de estado relevante).

De Request.CreateErrorResponse(HttpStatusCode, message) debe usar Request.CreateErrorResponse(HttpStatusCode, message) si desea especificar un mensaje. Sin embargo, esto vincula el código al objeto Request , que no debería necesitar hacer.

Normalmente creo mi propio tipo de excepción “segura” que espero que el cliente sepa cómo manejar y envolver a todos los demás con un error genérico 500.

Usar un filtro de acción para manejar las excepciones se vería así:

 public class ApiExceptionFilterAttribute : ExceptionFilterAttribute { public override void OnException(HttpActionExecutedContext context) { var exception = context.Exception as ApiException; if (exception != null) { context.Response = context.Request.CreateErrorResponse(exception.StatusCode, exception.Message); } } } 

Entonces puedes registrarlo globalmente.

 GlobalConfiguration.Configuration.Filters.Add(new ApiExceptionFilterAttribute()); 

Este es mi tipo de excepción personalizado.

 using System; using System.Net; namespace WebApi { public class ApiException : Exception { private readonly HttpStatusCode statusCode; public ApiException (HttpStatusCode statusCode, string message, Exception ex) : base(message, ex) { this.statusCode = statusCode; } public ApiException (HttpStatusCode statusCode, string message) : base(message) { this.statusCode = statusCode; } public ApiException (HttpStatusCode statusCode) { this.statusCode = statusCode; } public HttpStatusCode StatusCode { get { return this.statusCode; } } } } 

Una excepción de ejemplo que mi API puede arrojar.

 public class NotAuthenticatedException : ApiException { public NotAuthenticatedException() : base(HttpStatusCode.Forbidden) { } } 

Puedes lanzar una HttpResponseException

 HttpResponseMessage response = this.Request.CreateErrorResponse(HttpStatusCode.BadRequest, "your message"); throw new HttpResponseException(response); 

Para Web API 2, mis métodos devuelven IHttpActionResult constantemente, así que uso …

 public IHttpActionResult Save(MyEntity entity) { .... return ResponseMessage( Request.CreateResponse( HttpStatusCode.BadRequest, validationErrors)); } 

puede usar ActionFilter personalizado en Web Api para validar el modelo

 public class DRFValidationFilters : ActionFilterAttribute { public override void OnActionExecuting(HttpActionContext actionContext) { if (!actionContext.ModelState.IsValid) { actionContext.Response = actionContext.Request .CreateErrorResponse(HttpStatusCode.BadRequest, actionContext.ModelState); //BadRequest(actionContext.ModelState); } } public override Task OnActionExecutingAsync(HttpActionContext actionContext, CancellationToken cancellationToken) { return Task.Factory.StartNew(() => { if (!actionContext.ModelState.IsValid) { actionContext.Response = actionContext.Request .CreateErrorResponse(HttpStatusCode.BadRequest, actionContext.ModelState); } }); } public class AspirantModel { public int AspirantId { get; set; } public string FirstName { get; set; } public string MiddleName { get; set; } public string LastName { get; set; } public string AspirantType { get; set; } [RegularExpression(@"^\(?([0-9]{3})\)?[-. ]?([0-9]{3})[-. ]?([0-9]{4})$", ErrorMessage = "Not a valid Phone number")] public string MobileNumber { get; set; } public int StateId { get; set; } public int CityId { get; set; } public int CenterId { get; set; } } [HttpPost] [Route("AspirantCreate")] [DRFValidationFilters] public IHttpActionResult Create(AspirantModel aspirant) { if (aspirant != null) { } else { return Conflict(); } return Ok(); 

}

Registre la clase CustomAttribute en webApiConfig.cs config.Filters.Add (new DRFValidationFilters ());

Aprovechando la respuesta de Manish Jain (que es para Web API 2 que simplifica las cosas):

1) Use estructuras de validación para responder tantos errores de validación como sea posible. Estas estructuras también se pueden usar para responder a solicitudes provenientes de formularios.

 public class FieldError { public String FieldName { get; set; } public String FieldMessage { get; set; } } // a result will be able to inform API client about some general error/information and details information (related to invalid parameter values etc.) public class ValidationResult { public bool IsError { get; set; } ///  /// validation message. It is used as a success message if IsError is false, otherwise it is an error message ///  public string Message { get; set; } = string.Empty; public List FieldErrors { get; set; } = new List(); public T Payload { get; set; } public void AddFieldError(string fieldName, string fieldMessage) { if (string.IsNullOrWhiteSpace(fieldName)) throw new ArgumentException("Empty field name"); if (string.IsNullOrWhiteSpace(fieldMessage)) throw new ArgumentException("Empty field message"); // appending error to existing one, if field already contains a message var existingFieldError = FieldErrors.FirstOrDefault(e => e.FieldName.Equals(fieldName)); if (existingFieldError == null) FieldErrors.Add(new FieldError {FieldName = fieldName, FieldMessage = fieldMessage}); else existingFieldError.FieldMessage = $"{existingFieldError.FieldMessage}. {fieldMessage}"; IsError = true; } public void AddEmptyFieldError(string fieldName, string contextInfo = null) { AddFieldError(fieldName, $"No value provided for field. Context info: {contextInfo}"); } } public class ValidationResult : ValidationResult { } 

2) La capa de servicio devolverá ValidationResult s, independientemente de si la operación fue exitosa o no. P.ej:

  public ValidationResult DoSomeAction(RequestFilters filters) { var ret = new ValidationResult(); if (filters.SomeProp1 == null) ret.AddEmptyFieldError(nameof(filters.SomeProp1)); if (filters.SomeOtherProp2 == null) ret.AddFieldError(nameof(filters.SomeOtherProp2 ), $"Failed to parse {filters.SomeOtherProp2} into integer list"); if (filters.MinProp == null) ret.AddEmptyFieldError(nameof(filters.MinProp)); if (filters.MaxProp == null) ret.AddEmptyFieldError(nameof(filters.MaxProp)); // validation affecting multiple input parameters if (filters.MinProp > filters.MaxProp) { ret.AddFieldError(nameof(filters.MinProp, "Min prop cannot be greater than max prop")); ret.AddFieldError(nameof(filters.MaxProp, "Check")); } // also specify a global error message, if we have at least one error if (ret.IsError) { ret.Message = "Failed to perform DoSomeAction"; return ret; } ret.Message = "Successfully performed DoSomeAction"; return ret; } 

3) API Controller construirá la respuesta en función del resultado de la función de servicio

Una opción es colocar prácticamente todos los parámetros como opcionales y realizar una validación personalizada que devuelva una respuesta más significativa. Además, me aseguro de no permitir que ninguna excepción vaya más allá del límite del servicio.

  [Route("DoSomeAction")] [HttpPost] public HttpResponseMessage DoSomeAction(int? someProp1 = null, string someOtherProp2 = null, int? minProp = null, int? maxProp = null) { try { var filters = new RequestFilters { SomeProp1 = someProp1 , SomeOtherProp2 = someOtherProp2.TrySplitIntegerList() , MinProp = minProp, MaxProp = maxProp }; var result = theService.DoSomeAction(filters); return !result.IsError ? Request.CreateResponse(HttpStatusCode.OK, result) : Request.CreateResponse(HttpStatusCode.BadRequest, result); } catch (Exception exc) { Logger.Log(LogLevel.Error, exc, "Failed to DoSomeAction"); return Request.CreateErrorResponse(HttpStatusCode.InternalServerError, new HttpError("Failed to DoSomeAction - internal error")); } } 

Use el método incorporado “InternalServerError” (disponible en ApiController):

 return InternalServerError(); //or... return InternalServerError(new YourException("your message")); 

Si está utilizando ASP.NET Web API 2, la forma más fácil es utilizar el ApiController Short-Method. Esto dará como resultado un BadRequestResult.

 return BadRequest("message"); 

Solo para actualizar sobre el estado actual de ASP.NET WebAPI. La interfaz ahora se llama IActionResult y la implementación no ha cambiado mucho:

 [JsonObject(IsReference = true)] public class DuplicateEntityException : IActionResult { public DuplicateEntityException(object duplicateEntity, object entityId) { this.EntityType = duplicateEntity.GetType().Name; this.EntityId = entityId; } ///  /// Id of the duplicate (new) entity ///  public object EntityId { get; set; } ///  /// Type of the duplicate (new) entity ///  public string EntityType { get; set; } public Task ExecuteResultAsync(ActionContext context) { var message = new StringContent($"{this.EntityType ?? "Entity"} with id {this.EntityId ?? "(no id)"} already exist in the database"); var response = new HttpResponseMessage(HttpStatusCode.Ambiguous) { Content = message }; return Task.FromResult(response); } #endregion } 

Para aquellos errores en los que modelstate.isvalid es falso, generalmente envío el error tal como lo arroja el código. Es fácil de entender para el desarrollador que está consumiendo mi servicio. Generalmente envío el resultado usando el código siguiente.

  if(!ModelState.IsValid) { List errorlist=new List(); foreach (var value in ModelState.Values) { foreach(var error in value.Errors) errorlist.Add( error.Exception.ToString()); //errorlist.Add(value.Errors); } HttpResponseMessage response = Request.CreateResponse(HttpStatusCode.BadRequest,errorlist);} 

Esto envía el error al cliente en el siguiente formato, que es básicamente una lista de errores:

  [ "Newtonsoft.Json.JsonReaderException: **Could not convert string to integer: abc. Path 'Country',** line 6, position 16.\r\n at Newtonsoft.Json.JsonReader.ReadAsInt32Internal()\r\n at Newtonsoft.Json.JsonTextReader.ReadAsInt32()\r\n at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.ReadForType(JsonReader reader, JsonContract contract, Boolean hasConverter, Boolean inArray)\r\n at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.PopulateObject(Object newObject, JsonReader reader, JsonObjectContract contract, JsonProperty member, String id)", "Newtonsoft.Json.JsonReaderException: **Could not convert string to integer: ab. Path 'State'**, line 7, position 13.\r\n at Newtonsoft.Json.JsonReader.ReadAsInt32Internal()\r\n at Newtonsoft.Json.JsonTextReader.ReadAsInt32()\r\n at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.ReadForType(JsonReader reader, JsonContract contract, Boolean hasConverter, Boolean inArray)\r\n at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.PopulateObject(Object newObject, JsonReader reader, JsonObjectContract contract, JsonProperty member, String id)" ]