¿Por qué debería usar IHttpActionResult en lugar de HttpResponseMessage?

He estado desarrollando con WebApi y he pasado a WebApi2, donde Microsoft ha introducido una nueva IHttpActionResultinterfaz que parece recomendada para usarse antes de devolver a HttpResponseMessage. Estoy confundido sobre las ventajas de esta nueva interfaz. Parece que principalmente proporciona una manera LIGERAMENTE más fácil de crear un HttpResponseMessage.

Yo diría que esto es "abstracción por el bien de la abstracción". ¿Me estoy perdiendo de algo? ¿Cuáles son las ventajas del mundo real que obtengo al usar esta nueva interfaz además de guardar una línea de código?

Old way (WebApi):

public HttpResponseMessage Delete(int id)
{
    var status = _Repository.DeleteCustomer(id);
    if (status)
    {
        return new HttpResponseMessage(HttpStatusCode.OK);
    }
    else
    {
        throw new HttpResponseException(HttpStatusCode.NotFound);
    }
}

Nueva forma (WebApi2):

public IHttpActionResult Delete(int id)
{
    var status = _Repository.DeleteCustomer(id);
    if (status)
    {
        //return new HttpResponseMessage(HttpStatusCode.OK);
        return Ok();
    }
    else
    {
        //throw new HttpResponseException(HttpStatusCode.NotFound);
        return NotFound();
    }
}

Puede decidir no usarlo IHttpActionResultporque su código existente crea uno HttpResponseMessageque no se ajusta a una de las respuestas enlatadas. Sin embargo, puede adaptarse HttpResponseMessagea IHttpActionResultusar la respuesta enlatada de ResponseMessage. Me tomó un tiempo resolver esto, así que quería publicarlo mostrando que no necesariamente tienes que elegir uno u otro:

public IHttpActionResult SomeAction()
{
   IHttpActionResult response;
   //we want a 303 with the ability to set location
   HttpResponseMessage responseMsg = new HttpResponseMessage(HttpStatusCode.RedirectMethod);
   responseMsg.Headers.Location = new Uri("http://customLocation.blah");
   response = ResponseMessage(responseMsg);
   return response;
}

Tenga en cuenta que ResponseMessagees un método de la clase base ApiControllerque su controlador debe heredar.

Aún puedes usar HttpResponseMessage. Esa capacidad no desaparecerá. Sentí lo mismo que usted y discutí extensamente con el equipo que no había necesidad de una abstracción adicional. Hubo algunos argumentos para tratar de justificar su existencia, pero nada que me convenció de que valiera la pena.

Es decir, hasta que vi esta muestra de Brad Wilson . Si construye IHttpActionResultclases de una manera que se puede encadenar, obtendrá la capacidad de crear un canal de respuesta de "nivel de acción" para generar el HttpResponseMessage. Debajo de las cubiertas, así es como ActionFiltersse implementan, sin embargo, el orden de estos ActionFiltersno es obvio al leer el método de acción, que es una razón por la que no soy un fanático de los filtros de acción.

Sin embargo, al crear un IHttpActionResultque se puede encadenar explícitamente en su método de acción, puede componer todo tipo de comportamiento diferente para generar su respuesta.

Aquí hay varios beneficios de IHttpActionResultmás HttpResponseMessagemencionado en Microsoft ASP.Net de Documentación :

• Simplifica la unidad de prueba de sus controladores.
• Mueve la lógica común para crear respuestas HTTP en clases separadas.
• Aclara la intención de la acción del controlador al ocultar los detalles de bajo nivel de la construcción de la respuesta.

Pero aquí hay algunas otras ventajas de usar que IHttpActionResultvale la pena mencionar:

• Respeto del principio de responsabilidad única : hace que los métodos de acción tengan la responsabilidad de atender las solicitudes HTTP y no los involucre en la creación de los mensajes de respuesta HTTP.
• Implementaciones útiles ya definidas en System.Web.Http.Results, a saber: Ok NotFound Exception Unauthorized BadRequest Conflict Redirect InvalidModelState( enlace a la lista completa )
• Utiliza Async y Await por defecto.
• Fácil de crear su propio ActionResult con solo implementar el ExecuteAsyncmétodo.
• puede usar ResponseMessageResult ResponseMessage(HttpResponseMessage response)para convertir HttpResponseMessage a IHttpActionResult .

// this will return HttpResponseMessage as IHttpActionResult
return ResponseMessage(httpResponseMessage); 

Esta es solo mi opinión personal y la gente del equipo de API web probablemente pueda expresarlo mejor, pero aquí está mi 2c.

En primer lugar, creo que no se trata de uno sobre otro. Puede usarlos según lo que desee hacer en su método de acción, pero para comprender el poder real de IHttpActionResult, es probable que necesite salir de esos métodos auxiliares convenientes ApiControllercomo Ok, por ejemplo ,NotFound , etc.

Básicamente, creo que una clase implementada IHttpActionResultcomo una fábrica deHttpResponseMessage . Con esa mentalidad, ahora se convierte en un objeto que necesita ser devuelto y en una fábrica que lo produce. En el sentido de programación general, puede crear el objeto usted mismo en ciertos casos y, en ciertos casos, necesita una fábrica para hacerlo. Igual que aquí.

Si desea devolver una respuesta que necesita ser construida a través de una lógica compleja, digamos muchos encabezados de respuesta, etc., puede abstraer toda esa lógica en una clase de resultado de acción implementada IHttpActionResulty usarla en múltiples métodos de acción para devolver la respuesta.

Otra ventaja de usar IHttpActionResultcomo tipo de retorno es que hace que el método de acción API web ASP.NET sea similar a MVC. Puede devolver cualquier resultado de acción sin quedar atrapado en los formateadores de medios.

Por supuesto, como señaló Darrel, puede encadenar los resultados de la acción y crear una potente microtubería similar a los propios manejadores de mensajes en la canalización API. Esto lo necesitará dependiendo de la complejidad de su método de acción.

Larga historia corta: no es IHttpActionResultversus HttpResponseMessage. Básicamente, es cómo quieres crear la respuesta. Hágalo usted mismo o a través de una fábrica.

La API de Web básicamente de retorno 4 tipo de objeto: void, HttpResponseMessage, IHttpActionResult, y otros tipos fuertes. La primera versión de la API web regresa, HttpResponseMessageque es un mensaje de respuesta HTTP bastante sencillo.

El IHttpActionResultfue introducido por WebAPI 2, que es una especie de envoltura de HttpResponseMessage. Contiene el ExecuteAsync()método para crear un HttpResponseMessage. Simplifica las pruebas unitarias de su controlador.

Otro tipo de retorno son clases de tipo fuerte serializadas por la API web utilizando un formateador de medios en el cuerpo de la respuesta. El inconveniente es que no puede devolver directamente un código de error como un 404. Todo lo que puede hacer es arrojar un HttpResponseExceptionerror.

Prefiero implementar la función de interfaz TaskExecuteAsync para IHttpActionResult. Algo como:

    public Task<HttpResponseMessage> ExecuteAsync(CancellationToken cancellationToken)
    {
        var response = _request.CreateResponse(HttpStatusCode.InternalServerError, _respContent);

        switch ((Int32)_respContent.Code)
        { 
            case 1:
            case 6:
            case 7:
                response = _request.CreateResponse(HttpStatusCode.InternalServerError, _respContent);
                break;
            case 2:
            case 3:
            case 4:
                response = _request.CreateResponse(HttpStatusCode.BadRequest, _respContent);
                break;
        } 

        return Task.FromResult(response);
    }

, donde _request es HttpRequest y _respContent es la carga útil.

Tenemos los siguientes beneficios de usar IHttpActionResultmás de HttpResponseMessage:

1. Al usar el IHttpActionResultsolo nos estamos concentrando en los datos que se enviarán, no en el código de estado. Así que aquí el código será más limpio y muy fácil de mantener.
2. Las pruebas unitarias del método del controlador implementado serán más fáciles.
3. Usos asyncy awaitpor defecto.