Почему я должен использовать IHttpActionResult вместо HttpResponseMessage?

Я работал с WebApi и перешел к WebApi2, где Microsoft представила новый IHttpActionResultинтерфейс, который, кажется, рекомендуется использовать вместо возврата a HttpResponseMessage. Я запутался в преимуществах этого нового интерфейса. Похоже, что в основном это просто НЕМНОГО более простой способ создания HttpResponseMessage.

Я бы сделал аргумент, что это «абстракция ради абстракции». Я что-то упускаю? Какие преимущества в реальном мире я получаю от использования этого нового интерфейса, кроме, возможно, сохранения строки кода?

Старый способ (WebApi):

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

Новый путь (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();
    }
}

Возможно, вы решите не использовать, IHttpActionResultпотому что ваш существующий код создает такой HttpResponseMessage, который не соответствует ни одному из стандартных ответов. Однако вы можете адаптироваться HttpResponseMessageк IHttpActionResultиспользованию постоянного ответа ResponseMessage. Мне потребовалось некоторое время, чтобы понять это, поэтому я хотел опубликовать это, показывая, что вам не обязательно выбирать один или другой:

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

Обратите внимание, ResponseMessageэто метод базового класса ApiController, от которого ваш контроллер должен наследовать.

Вы все еще можете использовать HttpResponseMessage. Эта возможность не исчезнет. Я чувствовал то же самое, что и вы, и много спорил с командой, что нет необходимости в дополнительной абстракции. Было несколько аргументов, чтобы попытаться оправдать его существование, но ничто не убедило меня в том, что оно того стоит.

То есть, пока я не увидел этот образец от Брэда Уилсона . Если вы создаете IHttpActionResultклассы так, чтобы их можно было объединить в цепочку, вы получаете возможность создать конвейер ответов «на уровне действия» для генерации HttpResponseMessage. Под покровами, это то, как ActionFiltersэто реализовано, однако порядок их ActionFiltersне очевиден при чтении метода действия, и это одна из причин, по которой я не фанат фильтров действий.

Однако, создавая, IHttpActionResultкоторый может быть явно связан в вашем методе действия, вы можете составить все виды различного поведения для генерации вашего ответа.

Вот несколько преимуществ IHttpActionResultнад HttpResponseMessageупомянутым в Microsoft ASP.Net документации :

• Упрощает модульное тестирование ваших контроллеров.
• Перемещает общую логику для создания HTTP-ответов в отдельные классы.
• Делает намерение действия контроллера более понятным, скрывая низкоуровневые детали построения ответа.

Но вот некоторые другие преимущества использования, о которых IHttpActionResultстоит упомянуть:

• Соблюдение принципа единой ответственности : заставить методы действий отвечать за обслуживание HTTP-запросов и не привлекать их к созданию ответных HTTP-сообщений.
• Полезные реализации, уже определенные в System.Web.Http.Results, а именно: Ok NotFound Exception Unauthorized BadRequest Conflict Redirect InvalidModelState( ссылка на полный список )
• Использует Async и Await по умолчанию.
• Легко создать собственный ActionResult, просто внедрив ExecuteAsyncметод.
• Вы можете использовать ResponseMessageResult ResponseMessage(HttpResponseMessage response)для преобразования HttpResponseMessage в IHttpActionResult .

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

Это только мое личное мнение, и ребята из команды веб-API, вероятно, могут сформулировать это лучше, но вот мой 2c.

Прежде всего, я думаю, что это не вопрос одного над другим. Вы можете использовать их оба в зависимости от того, что вы хотите сделать в вашем методе действия, но чтобы понять реальную силу IHttpActionResult, вам, вероятно, нужно будет выйти за пределы таких удобных вспомогательных методов ApiController, как Ok, NotFoundи т. Д.

В основном, я думаю, что класс реализуется IHttpActionResultкак фабрика HttpResponseMessage. С таким настроем он теперь становится объектом, который необходимо вернуть, и фабрикой, которая его производит. В общем смысле программирования, вы можете создать объект самостоятельно в определенных случаях, а в некоторых случаях вам нужна фабрика для этого. Тоже самое.

Если вы хотите вернуть ответ, который должен быть построен с помощью сложной логики, скажем, большого количества заголовков ответа и т. Д., Вы можете абстрагировать всю эту логику в реализующий класс действия IHttpActionResultи использовать его в нескольких методах действия для возврата ответа.

Еще одним преимуществом использования в IHttpActionResultкачестве возвращаемого типа является то, что он делает метод действия ASP.NET Web API похожим на MVC. Вы можете вернуть любой результат действия, не попадая в средства форматирования медиа.

Конечно, как отметил Даррел, вы можете объединить результаты действий и создать мощный микропроцесс, подобный самим обработчикам сообщений в конвейере API. Это вам понадобится в зависимости от сложности вашего метода действий.

Короче говоря - это не IHttpActionResultпротив HttpResponseMessage. По сути, это то, как вы хотите создать ответ. Сделай сам или через фабрику.

Web API в основном возвращает 4 типа объекта: void, HttpResponseMessage, IHttpActionResult, и другие сильные тип. Первая версия Web API возвращает HttpResponseMessageдовольно простое ответное сообщение HTTP.

Он IHttpActionResultбыл представлен WebAPI 2, который является своего рода оберткой HttpResponseMessage. Он содержит ExecuteAsync()метод для создания HttpResponseMessage. Это упрощает модульное тестирование вашего контроллера.

Другой тип возвращаемых данных - это классы со строгой типизацией, сериализуемые Web API с использованием средства форматирования мультимедиа в теле ответа. Недостатком было то, что вы не можете напрямую вернуть код ошибки, такой как 404. Все, что вы можете сделать, это выдать HttpResponseExceptionошибку.

Я бы предпочел реализовать интерфейсную функцию TaskExecuteAsync для IHttpActionResult. Что-то вроде:

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

где _request - HttpRequest, а _respContent - полезная нагрузка.

У нас есть следующие преимущества использования IHttpActionResultболее HttpResponseMessage:

1. При использовании IHttpActionResultмы концентрируемся только на данных для отправки, а не на коде состояния. Так что здесь код будет чище и очень прост в обслуживании.
2. Модульное тестирование реализованного метода контроллера будет проще.
3. Использует asyncи awaitпо умолчанию.