Pourquoi devrais-je utiliser IHttpActionResult au lieu de HttpResponseMessage?

Question

J'ai développé avec WebApi et suis passé à WebApi2 où Microsoft a introduit une nouvelle interface IHttpActionResult qui semble être recommandée à utiliser plutôt que de retourner un HttpResponseMessage. Je suis confus quant aux avantages de cette nouvelle interface. Il semble principalement offrir un moyen LÉGÈREMENT plus facile de créer un HttpResponseMessage.

Je dirais que c'est de "l'abstraction pour l'abstraction". Est-ce que je rate quelque chose? Quels sont les avantages réels que j'obtiens en utilisant cette nouvelle interface, à part peut-être économiser une ligne de code?

Ancienne méthode (WebApi):

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

Nouvelle méthode (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();
    }
}

Answer 1

L'API Web retourne essentiellement 4 types d'objets : void, HttpResponseMessage, IHttpActionResult et d'autres types forts. La première version de l'API Web renvoie HttpResponseMessage qui est un message de réponse HTTP assez simple.

IHttpActionResult a été introduit par WebAPI 2 qui est une sorte d'enveloppe de HttpResponseMessage. Il contient la méthode ExecuteAsync() pour créer un HttpResponseMessage. Cela simplifie les tests unitaires de votre contrôleur.

Les autres types de retour sont des classes de types forts sérialisées par l'API Web à l'aide d'un formateur multimédia dans le corps de la réponse. L'inconvénient est que vous ne pouvez pas retourner directement un code d'erreur tel qu'un 404. Tout ce que vous pouvez faire est de déclencher une erreur HttpResponseException.

Answer 2

Je préfère implémenter la fonction de l'interface TaskExecuteAsync pour IHttpActionResult. Quelque chose comme :

    public Task 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);
    }

, où _request est la requête HttpRequest et _respContent est la charge utile.

Answer 3

Nous avons les avantages suivants de l'utilisation de IHttpActionResult par rapport à HttpResponseMessage:

1. En utilisant IHttpActionResult, nous nous concentrons uniquement sur les données à envoyer, pas sur le code d'état. Ainsi, le code sera plus propre et très facile à maintenir.
2. Les tests unitaires de la méthode du contrôleur implémenté seront plus faciles.
3. Utilise async et await par défaut.