Moje dwa centy za korzystanie z interfejsu IHttpActionResult w WebAPI

WebAPI Microsoftu od dłuższego czasu stanowi podstawę do tworzenia usług RESTful, które mogą pracować przez HTTP. Interfejs IHttpActionResult został wprowadzony z interfejsem WebAPI w wersji 2 i zapewnia inny sposób wysyłania odpowiedzi zwrotnych z metod kontrolera WebAPI oraz domyślnie wykorzystuje async i await.

Zasadniczo IHttpActionResult jest fabryką HttpResponsemessage. Interfejs IHttpActionResult znajduje się w przestrzeni nazw System.Web.Http i asynchronicznie tworzy wystąpienie HttpResponseMessage. IHttpActionResult zawiera kolekcję niestandardowych wbudowanych odpowiedzi, które obejmują: Ok, BadRequest, Exception, Conflict, Redirect, NotFound i Unauthorized.

Interfejs IHttpActionResult zawiera tylko jedną metodę. Oto jak wygląda ten interfejs:

namespace System.Web.Http

{

    public interface IHttpActionResult

    {

        Task ExecuteAsync(CancellationToken cancellationToken);

    }

}

Możesz zwrócić niestandardową odpowiedź przy użyciu dowolnej z metod pomocniczych klasy ApiController wymienionych poniżej.

Ok

NotFound

Exception

Unauthorized

BadRequest

Conflict

Redirect

InvalidModelState

Zwracanie odpowiedzi z metod kontrolera WebAPI

W tej sekcji omówimy, w jaki sposób możemy wykorzystać IHttpActionResult do wysyłania odpowiedzi zwrotnych z metod kontrolera.

Rozważmy teraz następujący kontroler WebApi:

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

        }

    }

Należy zauważyć, że w każdym przypadku zwracany jest odpowiedni kod stanu, tj. Jeśli dane są dostępne, zwracany jest HttpStatusCode.OK, a HttpStatusCode.NotFound jest zwracany, jeśli dane nie są dostępne.

Zobaczmy teraz, jak można zmienić tę samą metodę kontrolera, aby zwracała odpowiedź jako IHttpActionResult. Oto zaktualizowany kod metody kontrolera w celach informacyjnych. Zwróć uwagę, jak HttpResponseMessage został zastąpiony przez IHttpActionResult.

public IHttpActionResult Get(int id)

        {

            var result = repository.GetData(id);

            if (result == null)

                return NotFound();

            return Ok(result);

        }

Zapoznaj się z metodą Get podaną powyżej. Kod jest bardzo prosty i oszczędny, a także abstrakcyjny sposób, w jaki wiadomość HTTP jest faktycznie konstruowana w kontrolerze. A oto kolejny przykład.

Zapoznaj się z następującym fragmentem kodu, który zwraca HttpResponseMessage, aby zgłosić sukces lub niepowodzenie.

public HttpResponseMessage Delete(int id)

        {

            var status = repository.Delete(id);

            if (status)

               return new HttpResponseMessage(HttpStatusCode.OK);

            return new HttpResponseMessage(HttpStatusCode.NotFound);

        }

Teraz zobacz, jak można refaktoryzować tę samą metodę akcji przy użyciu IHttpActionResult, aby kod był znacznie bardziej oszczędny i prosty.

public IHttpActionResult Delete(int id)

        {

            var status = repository.Delete(id);

            if (status)

              return Ok();

            return NotFound();

        }

Którego powinienem użyć i dlaczego?

Czy więc powinniśmy używać IHttpActionResult zamiast HttpResponseMessage w naszych kontrolerach WebAPI podczas wysyłania odpowiedzi? Oto moja odpowiedź na to pytanie. Zawsze wolałbym IHttpActionResult zamiast HttpResponseMessage, ponieważ w ten sposób testy jednostkowe kontrolerów zostałyby uproszczone. Możesz przenieść wspólną logikę tworzenia odpowiedzi HTTP do innych klas i sprawić, że metody kontrolera będą oszczędne i proste. W istocie szczegóły niskiego poziomu tworzenia odpowiedzi HTTP byłyby hermetyzowane.

Z drugiej strony warto wspomnieć, że korzystając z IHttpActionResult, możesz przestrzegać zasady pojedynczej odpowiedzialności, a metody akcji mogą skupiać się na obsłudze żądań HTTP zamiast konstruować komunikaty odpowiedzi HTTP. Jest jeszcze jedna kwestia, o której warto wspomnieć. Możesz skorzystać z IHttpActionResult, aby zapewnić obsługę HTML z Razor. Wszystko, co musisz zrobić, to utworzyć wynik akcji niestandardowej, który może analizować widoki Razor. Tworzenie wyniku akcji niestandardowej jest proste. Wystarczy rozszerzyć interfejs IHttpActionResult, a następnie zaimplementować własną wersję metody ExecuteAsync.