Mes deux cents sur l'utilisation de l'interface IHttpActionResult dans WebAPI

WebAPI de Microsoft est depuis un certain temps le cadre de choix pour créer des services RESTful pouvant fonctionner sur HTTP. L'interface IHttpActionResult a été introduite avec WebAPI version 2 et fournit une manière différente de renvoyer des réponses à partir de vos méthodes de contrôleur WebAPI, et elle exploite async et wait par défaut.

Essentiellement, IHttpActionResult est une fabrique pour HttpResponsemessage. L'interface IHttpActionResult est contenue dans l'espace de noms System.Web.Http et crée une instance de HttpResponseMessage de manière asynchrone. Le IHttpActionResult comprend une collection de réponses intégrées personnalisées qui incluent: Ok, BadRequest, Exception, Conflict, Redirect, NotFound et Unauthorized.

L'interface IHttpActionResult contient une seule méthode. Voici à quoi ressemble cette interface:

namespace System.Web.Http

{

    public interface IHttpActionResult

    {

        Task ExecuteAsync(CancellationToken cancellationToken);

    }

}

Vous pouvez renvoyer une réponse personnalisée à l'aide de l'une des méthodes d'assistance de la classe ApiController répertoriées ci-dessous.

Ok

NotFound

Exception

Unauthorized

BadRequest

Conflict

Redirect

InvalidModelState

Retour de la réponse des méthodes du contrôleur WebAPI

Dans cette section, nous explorerons comment nous pouvons tirer parti de IHttpActionResult pour renvoyer des réponses à partir des méthodes du contrôleur.

Maintenant, considérez le contrôleur WebApi suivant:

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);

        }

    }

Notez que le code d'état approprié est renvoyé dans chaque cas, c'est-à-dire que si des données sont disponibles, HttpStatusCode.OK est renvoyé tandis que HttpStatusCode.NotFound est renvoyé si les données ne sont pas disponibles.

Voyons maintenant comment la même méthode de contrôleur peut être modifiée pour renvoyer la réponse en tant que IHttpActionResult. Voici le code mis à jour de la méthode du contrôleur pour votre référence. Notez comment HttpResponseMessage a été remplacé par IHttpActionResult.

public IHttpActionResult Get(int id)

        {

            var result = repository.GetData(id);

            if (result == null)

                return NotFound();

            return Ok(result);

        }

Reportez-vous à la méthode Get donnée ci-dessus. Le code est beaucoup plus simple et léger et il résume la façon dont le message Http est réellement construit dans le contrôleur. Et voici un autre exemple.

Reportez-vous à l'extrait de code suivant qui renvoie HttpResponseMessage pour signaler la réussite ou l'échec.

public HttpResponseMessage Delete(int id)

        {

            var status = repository.Delete(id);

            if (status)

               return new HttpResponseMessage(HttpStatusCode.OK);

            return new HttpResponseMessage(HttpStatusCode.NotFound);

        }

Maintenant, voyez comment la même méthode d'action peut être refactorisée à l'aide de IHttpActionResult pour rendre le code beaucoup plus léger et simple.

public IHttpActionResult Delete(int id)

        {

            var status = repository.Delete(id);

            if (status)

              return Ok();

            return NotFound();

        }

Lequel dois-je utiliser et pourquoi?

Alors, devrions-nous utiliser IHttpActionResult sur HttpResponseMessage dans nos contrôleurs WebAPI lors du renvoi des réponses? Voici ma réponse à cette question. Je préférerais toujours IHttpActionResult à HttpResponseMessage car, ce faisant, les tests unitaires des contrôleurs seraient simplifiés. Vous pouvez déplacer la logique commune de création de réponses Http vers d'autres classes et simplifier et simplifier vos méthodes de contrôleur. En substance, les détails de bas niveau de création des réponses Http seraient encapsulés.

Sur une note différente, il convient de mentionner qu'en utilisant IHttpActionResult, vous pouvez adhérer au principe de responsabilité unique et vos méthodes d'action peuvent se concentrer sur la gestion des requêtes Http plutôt que sur la construction des messages de réponse Http. Il y a un autre point qui mérite d'être mentionné. Vous pouvez tirer parti de IHttpActionResult pour prendre en charge HTML avec Razor. Tout ce que vous avez à faire est de créer un résultat d'action personnalisé qui peut analyser les vues Razor. La création d'un résultat d'action personnalisé est simple. Il vous suffit d'étendre l'interface IHttpActionResult, puis d'implémenter votre propre version de la méthode ExecuteAsync.