Dlaczego powinienem używać IHttpActionResult zamiast HttpResponseMessage?

Pracowałem z WebApi i przeniosłem się na WebApi2, gdzie Microsoft wprowadził nowy IHttpActionResultinterfejs, który wydaje się zalecany do użycia zamiast zwracania HttpResponseMessage. Jestem zdezorientowany zaletami tego nowego interfejsu. Wydaje się, że głównie zapewnia PO LEKKO łatwiejszy sposób utworzenia HttpResponseMessage.

Argumentowałbym, że jest to „abstrakcja ze względu na abstrakcję”. Czy coś brakuje? Jakie są rzeczywiste korzyści płynące z korzystania z tego nowego interfejsu oprócz oszczędzania linii kodu?

Stary sposób (WebApi):

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

Nowa droga (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();
    }
}

Możesz zdecydować, aby nie używać, IHttpActionResultponieważ istniejący kod buduje taki HttpResponseMessage, który nie pasuje do jednej z odpowiedzi w puszce. Możesz jednak dostosować się HttpResponseMessagedo IHttpActionResultkorzystania z konserwowanej odpowiedzi programu ResponseMessage. Zajęło mi to trochę czasu, aby to rozgryźć, więc chciałem to opublikować, pokazując, że niekoniecznie musisz wybierać jedno lub drugie:

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

Uwaga: ResponseMessagejest metodą klasy podstawowej ApiController, z której kontroler powinien dziedziczyć.

Nadal możesz używać HttpResponseMessage. Ta zdolność nie zniknie. Czułam to samo co ty i szeroko argumentowałam z zespołem, że nie ma potrzeby dodatkowej abstrakcji. Pojawiło się kilka argumentów, aby spróbować uzasadnić jego istnienie, ale nic nie przekonało mnie, że warto.

To znaczy, dopóki nie zobaczyłem tej próbki od Brada Wilsona . Jeśli konstruujesz IHttpActionResultklasy w sposób, który można połączyć w łańcuch, zyskujesz możliwość stworzenia potoku odpowiedzi „na poziomie akcji” do wygenerowania HttpResponseMessage. ActionFiltersJednak pod przykrywkami jest to realizowane, ale ich kolejność ActionFiltersnie jest oczywista podczas czytania metody akcji, co jest jednym z powodów, dla których nie jestem fanem filtrów akcji.

Jednak tworząc metodę, IHttpActionResultktóra może być wyraźnie powiązana w metodzie działania, możesz skomponować różne zachowania, aby wygenerować odpowiedź.

Oto kilka korzyści IHttpActionResultponad HttpResponseMessagewymienione w Microsoft ASP.NET Dokumentacja :

• Upraszcza testowanie jednostek przez kontrolery.
• Przenosi wspólną logikę tworzenia odpowiedzi HTTP do oddzielnych klas.
• Wyjaśnia cel działania kontrolera, ukrywając niskiego poziomu szczegóły konstruowania odpowiedzi.

IHttpActionResultWarto jednak wspomnieć o kilku innych zaletach używania :

• Poszanowanie zasady pojedynczej odpowiedzialności : powoduje, że metody działania są odpowiedzialne za obsługę żądań HTTP i nie angażują ich w tworzenie komunikatów odpowiedzi HTTP.
• Przydatne implementacje zdefiniowane już w System.Web.Http.Results, a mianowicie: Ok NotFound Exception Unauthorized BadRequest Conflict Redirect InvalidModelState( link do pełnej listy )
• Używa Async i OczekujeDomyślnie .
• Łatwe tworzenie własnych ActionResult po prostu poprzez wdrożenieExecuteAsync metody.
• możesz użyć ResponseMessageResult ResponseMessage(HttpResponseMessage response)do konwersji HttpResponseMessage na IHttpActionResult .

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

To tylko moja osobista opinia i ludzie z zespołu API mogą prawdopodobnie lepiej to wyrazić, ale oto mój 2c.

Przede wszystkim myślę, że nie jest to kwestia jednego nad drugim. Możesz użyć ich obu w zależności od tego, co chcesz zrobić w metodzie działania, ale aby zrozumieć prawdziwą moc IHttpActionResult, prawdopodobnie będziesz musiał wyjść poza te wygodne metody pomocnicze, ApiControllertakie jak Ok:NotFound itp

Zasadniczo myślę, że klasa wdrażająca IHttpActionResultjako fabrykaHttpResponseMessage . Po takim nastawieniu staje się teraz przedmiotem, który należy zwrócić, i fabryką, która go wytwarza. W ogólnym sensie programowania możesz w niektórych przypadkach sam stworzyć obiekt, aw niektórych przypadkach potrzebujesz fabryki, aby to zrobić. To samo tutaj.

Jeśli chcesz zwrócić odpowiedź, która musi zostać zbudowana za pomocą złożonej logiki, powiedzmy, wiele nagłówków odpowiedzi itp., Możesz wyodrębnić całą tę logikę do implementacji klasy wyników akcji IHttpActionResulti użyć jej w wielu metodach akcji, aby zwrócić odpowiedź.

Kolejną zaletą używania IHttpActionResultjako typu zwracanego jest to, że sprawia, że ​​metoda akcji ASP.NET Web API jest podobna do MVC. Możesz zwrócić dowolny wynik akcji, nie wpadając w formaty mediów.

Oczywiście, jak zauważył Darrel, możesz łączyć wyniki działań i tworzyć potężny mikroprocesor podobny do samych programów obsługi komunikatów w potoku API. Będzie to potrzebne w zależności od złożoności metody działania.

Krótko mówiąc - to nie jest IHttpActionResultkontra HttpResponseMessage. Zasadniczo tak właśnie chcesz utworzyć odpowiedź. Zrób to sam lub przez fabrykę.

Web API zasadzie powrotu 4 Typ obiektu: void, HttpResponseMessage, IHttpActionResultoraz inne silne typy. Zwraca pierwszą wersję interfejsu API sieci Web, HttpResponseMessagektóra jest dość prostym komunikatem odpowiedzi HTTP.

IHttpActionResultWprowadził WebAPI 2, który jest w rodzaju opasania HttpResponseMessage. Zawiera ExecuteAsync()metodę tworzenia HttpResponseMessage. Upraszcza testowanie jednostkowe kontrolera.

Innym typem zwracanym są rodzaj silnie typowanych klas serializowanych przez interfejs API sieci Web przy użyciu formatera multimediów w treści odpowiedzi. Wadą jest to, że nie można bezpośrednio zwrócić kodu błędu, takiego jak 404. Wszystko, co możesz zrobić, to zgłosić HttpResponseExceptionbłąd.

Wolę zaimplementować funkcję interfejsu TaskExecuteAsync dla IHttpActionResult. Coś jak:

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

, gdzie _request to HttpRequest, a _respContent to ładunek.

Mamy następujące zalety korzystania z IHttpActionResultponad HttpResponseMessage:

1. Korzystając z IHttpActionResult, koncentrujemy się tylko na przesyłanych danych, a nie na kodzie statusu. Więc tutaj kod będzie czystszy i bardzo łatwy w utrzymaniu.
2. Testy jednostkowe zaimplementowanej metody sterownika będą łatwiejsze.
3. Używa asynci awaitdomyślnie.