He venido desarrollando con WebApi y se han trasladado a WebApi2 donde Microsoft ha introducido una nueva IHttpActionResult Interfaz que parece recomienda para ser utilizado sobre la devolución de un HttpResponseMessage. Estoy confundido sobre las ventajas de esta nueva Interfaz. Parece principalmente a proporcionar sólo una LIGERAMENTE manera más fácil de crear un HttpResponseMessage.

Me gustaría hacer el argumento de que esta es la «abstracción para el bien de la abstracción». Me estoy perdiendo algo? ¿Qué es el mundo real ventajas obtengo con el uso de esta nueva Interfaz, además de tal vez de guardar una línea de código?

Antiguo camino (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();
    }
}
  • Acabo de encontrar algo interesante. No estoy seguro de si estos resultados pueden ser verificados por alguien más. Pero el rendimiento ha mejorado mucho con algunas de las llamadas que hice: * Con un ejemplo el uso de HttpResponseMessage tengo la respuesta en el 9545 ms. * El uso de la IHttpActionResult me dieron la misma respuesta en el 294 ms.
InformationsquelleAutor Jason Roell | 2014-02-13

8 Comentarios

  1. 288

    Usted podría decidir no utilizar IHttpActionResult debido a que su código existente construye un HttpResponseMessage que no encaje en una de las respuestas prediseñadas. Sin embargo, puede adaptarse HttpResponseMessage a IHttpActionResult el uso de la respuesta enlatada de ResponseMessage. Me tomó un tiempo para averiguar esto, así que quería publicar lo que muestra que no necesariamente se tiene que elegir uno o el 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;
    }

    Nota, ResponseMessage es un método de la clase base ApiController que el controlador debe heredar.

    • Me tomó un tiempo para averiguar que ResponseMessage es ahora ResponseMessageResult. Tal vez ha cambiado de nombre recientemente? P. S. también ha perdido una nueva palabra clave en la respuesta y muchas gracias por la sugerencia 🙂
    • y ResponseMessageResult son dos cosas diferentes. ResponseMessage() es un método de ApiController que el controlador debe heredar de, y por lo tanto es sólo una llamada de método. Así que no new palabra clave es necesaria allí. Usted probablemente no son la herencia de ApiController o está dentro de un método estático. ResponseMessageResult es el tipo de retorno de ResponseMessage().
    • Yo podría haber escrito response = base.ResponseMessage(responseMsg) para hacerla más clara de que es un método de la clase base ApiController
    • Gracias, yo tenía un servicio hecho que no se heredan de ApiController, por lo que tomó un poco de tiempo para encontrar.
    • esto en realidad no respuesta OPs pregunta..
    • Tienes razón, me dirigí al hecho de que el OP parece dar a entender que creían que los dos enfoques son mutuamente excluyentes, por el encuadre como «vieja manera» vs «nueva forma», cuando en realidad no lo son. Creo que Darrel la respuesta de hace un buen trabajo de explicar algunos de los beneficios de la devolución de IHttpActionResult, y mi respuesta se muestra cómo usted es capaz de convertir el antiguo HttpResponseMessage en un IHttpActionResult de modo que usted puede tener lo mejor de ambos mundos.
    • es correcto. Debe ser return new ResponseMessageResult(new HttpResponseMessage(HttpStatusCode.RedirectMethod));

  2. 83

    Todavía puede utilizar HttpResponseMessage. Esa capacidad no va a desaparecer. Me sentí de la misma manera como usted y discutido ampliamente con el equipo que no había necesidad de un adicional de abstracción. Hubo un par de argumentos lanzado a probar y justificar su existencia, pero nada de lo que me convenció de que valía la pena.

    Que es, hasta que vi este muestra de Brad Wilson. Si usted construir IHttpActionResult clases de una manera que puede ser encadenado, obtiene la capacidad de crear un «acción» del nivel respuesta de canalización para la generación de la HttpResponseMessage. Bajo las cubiertas, esta es la forma en ActionFilters se implementan sin embargo, el orden de los ActionFilters no es evidente al leer el método de acción que es la razón yo no soy un fan de los filtros de acción.

    Sin embargo, mediante la creación de un IHttpActionResult que puede ser explícitamente encadenado en su método de acción puede redactar todo tipo de comportamiento diferente para generar la respuesta.

  3. 59

    Aquí son varios los beneficios de IHttpActionResult más de HttpResponseMessage mencionado en Microsoft ASP.Net Documentación:

    • Simplifica la unidad de pruebas de los controladores.
    • Mueve la lógica común para la creación de las respuestas HTTP en clases separadas.
    • Hace que la intención de la acción del controlador más clara, ocultando los detalles de bajo nivel de construcción de la respuesta.

    Pero aquí hay algunas otras ventajas de la utilización de IHttpActionResult vale la pena mencionar:

    • Respetando el principio de responsabilidad único: causa en los métodos de acción que tienen la responsabilidad de servir las peticiones HTTP y no involucrarlos en la creación de los mensajes de respuesta HTTP.
    • Útil implementaciones que ya están definidas en el Sistema.Web.Http.Resultados 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 sólo mediante la implementación de ExecuteAsync método.
    • puede utilizar ResponseMessageResult ResponseMessage(HttpResponseMessage response) a convertir HttpResponseMessage a IHttpActionResult.
  4. 32
    //this will return HttpResponseMessage as IHttpActionResult
    return ResponseMessage(httpResponseMessage); 
  5. 17

    Esto es sólo mi opinión personal y la gente de la web de la API de equipo probablemente puede articular mejor, pero aquí está mi 2c.

    Primero de todo, yo creo que no es una pregunta de uno sobre otro. Usted puede utilizar ambos, dependiendo de lo que desee hacer en su método de acción, pero con el fin de comprender el verdadero poder de IHttpActionResult, usted probablemente tendrá que dar un paso fuera de esos conveniente métodos auxiliares de ApiController como Ok, NotFound, etc.

    Básicamente, creo una clase que implementa IHttpActionResult como una fábrica de HttpResponseMessage. Con eso en mente, ahora se convierte en un objeto que necesita ser devuelto y una fábrica que produce. En general, la programación sentido, puede crear el objeto en sí mismo, en ciertos casos, y en algunos casos, se necesita de una fábrica para hacer eso. Mismo aquí.

    Si quieres devolver una respuesta que debe ser construido a través de una lógica compleja, dicen mucho de los encabezados de respuesta, etc, usted puede abstracto a todos aquellos lógica en un resultado de una acción de clase de la aplicación de IHttpActionResult y utilizar en múltiples métodos de acción para devolver la respuesta.

    Otra ventaja de usar IHttpActionResult como tipo de retorno es que hace ASP.NET Web API método de acción similar a la de la MVC. Usted puede devolver cualquier resultado de una acción sin quedar atrapados en los medios de comunicación formatters.

    De curso, como se señaló por Darrel, puedes cadena de resultados de la acción y crear un potente micro-tubería similar a message handlers en la API de tubería. Esto se necesita en función de la complejidad de su método de acción.

    Cortocircuito largo de la historia – no es IHttpActionResult frente a HttpResponseMessage. Básicamente, es la forma en que desea crear la respuesta. Hágalo usted mismo o a través de una fábrica.

    • El problema que tuve con la fábrica justfication es que puedo crear con facilidad métodos estáticos como ResponseFactory.CreateOkResponse() que volver HttpResponseMessage, y no tuve que lidiar con la async cosas a la hora de crear la respuesta. Un miembro del equipo que hizo mención el hecho de que el asíncrono puede ser útil si usted necesita para hacer de e/S con el fin de generar valores de encabezado. No está seguro de cómo a menudo que eso vaya a suceder.
    • Creo que es igual a decir por qué necesitamos la fábrica método patrón. ¿Por qué no utilizar métodos estáticos para crear objetos. Claro, es factible – cada objeto de la creación no merecen un adecuado patrón de fábrica. Pero, a continuación, en mi humilde opinión, todo depende de cómo usted quiere ser un modelo de clases. ¿Quieres tener lógica para crear diferentes tipos de respuestas de todos hacinados en una clase en la forma de múltiples métodos estáticos o tienen diferentes clases basadas en una interfaz. De nuevo, no hay bueno o malo. Todo depende. De todos modos, mi punto es que no es de uno sobre otro y que personalmente me gusta fábrica cosa mejor 🙂
  6. 5

    La Web de la API, básicamente, volver 4 tipo de objeto: void, HttpResponseMessage, IHttpActionResult, y el resto de los tipos. La primera versión de la Web de la API devuelve HttpResponseMessage que es bastante sencillo mensaje de respuesta HTTP.

    La IHttpActionResult fue introducido por WebAPI 2, que es una especie de envoltura de HttpResponseMessage. Contiene la ExecuteAsync() método para crear un HttpResponseMessage. Simplifica la unidad de pruebas de su controlador.

    Otro tipo de retorno son una especie de fuerte escribió clases serializado por la API de Web usando un formateador de los medios de comunicación en el cuerpo de la respuesta. La desventaja es que directamente no se puede devolver un código de error como un error 404. Todo lo que puedes hacer es tirar un HttpResponseException error.

  7. 3

    Prefiero implementar TaskExecuteAsync función de interfaz para IHttpActionResult. Algo así 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 el HttpRequest y _respContent es la carga útil.

  8. 1

    Tenemos los siguientes beneficios de la utilización de IHttpActionResult más de HttpResponseMessage:

    1. Mediante el IHttpActionResult sólo estamos concentrando en los datos a enviar, no en el código de estado. Así que aquí el código será más limpio y muy fáciles de mantener.
    2. Unidad de pruebas de la aplicación de controlador método será más fácil.
    3. Utiliza async y await por defecto.

Dejar respuesta

Please enter your comment!
Please enter your name here