Mis dos centavos en el uso de la interfaz IHttpActionResult en WebAPI

WebAPI de Microsoft ha sido durante bastante tiempo el marco de trabajo elegido para crear servicios RESTful que pueden funcionar a través de HTTP. La interfaz IHttpActionResult se introdujo con la versión 2 de WebAPI y proporciona una forma diferente de enviar respuestas desde los métodos de su controlador WebAPI, y aprovecha async y await de forma predeterminada.

Básicamente, IHttpActionResult es una fábrica de HttpResponsemessage. La interfaz IHttpActionResult está contenida en el espacio de nombres System.Web.Http y crea una instancia de HttpResponseMessage de forma asincrónica. El IHttpActionResult comprende una colección de respuestas integradas personalizadas que incluyen: Ok, BadRequest, Exception, Conflict, Redirect, NotFound y Unauthorized.

La interfaz IHttpActionResult contiene solo un método. Así es como se ve esta interfaz:

namespace System.Web.Http

{

    public interface IHttpActionResult

    {

        Task ExecuteAsync(CancellationToken cancellationToken);

    }

}

Puede devolver una respuesta personalizada utilizando cualquiera de los métodos auxiliares de la clase ApiController que se enumeran a continuación.

Ok

NotFound

Exception

Unauthorized

BadRequest

Conflict

Redirect

InvalidModelState

Devolver respuesta de los métodos del controlador WebAPI

En esta sección, exploraremos cómo podemos aprovechar IHttpActionResult para enviar respuestas desde los métodos del controlador.

Ahora, considere el siguiente controlador WebApi:

public class DefaultController : ApiController

    {

        private readonly DemoRepository repository = new DemoRepository();

        public HttpResponseMessage Get(int id)

        {

            var result = repository.GetData(id);

            if (result != null)

                return Request.CreateResponse(HttpStatusCode.OK, result);

            return Request.CreateResponse(HttpStatusCode.NotFound);

        }

    }

Tenga en cuenta que se devuelve el código de estado apropiado en cada caso, es decir, si hay datos disponibles, se devuelve HttpStatusCode.OK mientras que se devuelve HttpStatusCode.NotFound si los datos no están disponibles.

Veamos ahora cómo se puede cambiar el mismo método de controlador para devolver la respuesta como IHttpActionResult. Aquí está el código actualizado del método del controlador para su referencia. Observe cómo HttpResponseMessage ha sido reemplazado por IHttpActionResult.

public IHttpActionResult Get(int id)

        {

            var result = repository.GetData(id);

            if (result == null)

                return NotFound();

            return Ok(result);

        }

Consulte el método Get proporcionado anteriormente. El código es mucho más simple y ajustado y abstrae la forma en que el mensaje Http está realmente construido en el controlador. Y aquí hay otro ejemplo.

Consulte el siguiente fragmento de código que devuelve HttpResponseMessage para informar el éxito o el fracaso.

public HttpResponseMessage Delete(int id)

        {

            var status = repository.Delete(id);

            if (status)

               return new HttpResponseMessage(HttpStatusCode.OK);

            return new HttpResponseMessage(HttpStatusCode.NotFound);

        }

Ahora vea cómo se puede refactorizar el mismo método de acción usando IHttpActionResult para hacer que el código sea mucho más ágil y simple.

public IHttpActionResult Delete(int id)

        {

            var status = repository.Delete(id);

            if (status)

              return Ok();

            return NotFound();

        }

¿Cuál debo usar y por qué?

Entonces, ¿deberíamos usar IHttpActionResult sobre HttpResponseMessage en nuestros controladores WebAPI al enviar las respuestas? Aquí está mi respuesta a esta pregunta. Siempre preferiría IHttpActionResult sobre HttpResponseMessage, ya que al hacerlo, las pruebas unitarias de los controladores se simplificarían. Puede mover la lógica común para crear respuestas Http a otras clases y hacer que sus métodos de controlador sean simples y ajustados. En esencia, se encapsularían los detalles de bajo nivel de la creación de las respuestas Http.

En una nota diferente, vale la pena mencionar que al usar IHttpActionResult, puede adherirse al Principio de Responsabilidad Única y sus métodos de acción pueden enfocarse en manejar las solicitudes Http en lugar de construir los mensajes de respuesta Http. Hay otro punto que vale la pena mencionar. Puede aprovechar IHttpActionResult para proporcionar compatibilidad con HTML con Razor. Todo lo que necesita hacer es crear un resultado de acción personalizado que pueda analizar las vistas de Razor. Crear un resultado de acción personalizado es simple. Solo necesitaría extender la interfaz IHttpActionResult y luego implementar su propia versión del método ExecuteAsync.