Двата ми цента за използване на интерфейса IHttpActionResult в WebAPI

WebAPI на Microsoft от доста време е избрана рамка за изграждане на RESTful услуги, които могат да работят през HTTP. Интерфейсът IHttpActionResult е въведен с WebAPI версия 2 и осигурява различен начин за изпращане на отговори от методите на вашия WebAPI контролер и използва асинхронизация и изчакване по подразбиране.

По същество IHttpActionResult е фабрика за HttpResponsemessage. Интерфейсът IHttpActionResult се съдържа в пространството от имена System.Web.Http и асинхронно създава екземпляр на HttpResponseMessage. IHttpActionResult включва колекция от персонализирани вградени отговори, които включват: Ok, BadRequest, Exception, Conflict, Redirect, NotFound и Unauthorized.

Интерфейсът IHttpActionResult съдържа само един метод. Ето как изглежда този интерфейс:

namespace System.Web.Http

{

    public interface IHttpActionResult

    {

        Task ExecuteAsync(CancellationToken cancellationToken);

    }

}

Можете да върнете персонализиран отговор, като използвате някой от помощните методи на класа ApiController, изброени по-долу.

Ok

NotFound

Exception

Unauthorized

BadRequest

Conflict

Redirect

InvalidModelState

Връщане на отговор от методи на WebAPI контролер

В този раздел ще проучим как можем да използваме IHttpActionResult за изпращане на отговори от методите на контролера.

Сега помислете за следния контролер 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);

        }

    }

Обърнете внимание, че съответният код на състоянието се връща във всеки отделен случай, т.е. ако данните са налични, HttpStatusCode.OK се връща, докато HttpStatusCode.NotFound се връща, ако данните не са налични.

Нека сега видим как същият метод на контролера може да бъде променен, за да върне отговора като IHttpActionResult. Ето актуализирания код на метода на контролера за справка. Обърнете внимание как HttpResponseMessage е заменен с IHttpActionResult.

public IHttpActionResult Get(int id)

        {

            var result = repository.GetData(id);

            if (result == null)

                return NotFound();

            return Ok(result);

        }

Обърнете се към метода Get, даден по-горе. Кодът е много прост и по-слаб и абстрахира начина, по който всъщност се изгражда съобщението Http в контролера. И ето още един пример.

Обърнете се към следния кодов фрагмент, който връща HttpResponseMessage, за да отчете успех или неуспех.

public HttpResponseMessage Delete(int id)

        {

            var status = repository.Delete(id);

            if (status)

               return new HttpResponseMessage(HttpStatusCode.OK);

            return new HttpResponseMessage(HttpStatusCode.NotFound);

        }

Сега вижте как същият метод на действие може да бъде рефакториран с помощта на IHttpActionResult, за да направи кода много по-лек и опростен.

public IHttpActionResult Delete(int id)

        {

            var status = repository.Delete(id);

            if (status)

              return Ok();

            return NotFound();

        }

Кой да използвам и защо?

И така, трябва ли да използваме IHttpActionResult над HttpResponseMessage в нашите WebAPI контролери, когато изпращаме обратно отговорите? Ето отговора ми на този въпрос. Винаги бих предпочел IHttpActionResult пред HttpResponseMessage, тъй като при това тестването на модулите на контролерите ще бъде опростено. Можете да преместите общата логика за създаване на Http отговори в други класове и да направите методите на контролера си по-лесни и прости. По същество детайлите от ниското ниво за създаване на Http отговори ще бъдат капсулирани.

От друга бележка, заслужава да се спомене, че при използване на IHttpActionResult можете да се придържате към принципа на единната отговорност, както и вашите методи за действие да се съсредоточат върху обработката на Http заявките, вместо да конструират Http съобщенията за отговор. Има още един момент, който си струва да се спомене. Можете да се възползвате от IHttpActionResult, за да осигурите поддръжка за HTML с Razor. Всичко, което трябва да направите, е да създадете персонализиран резултат от действие, който може да анализира изгледите на Razor. Създаването на резултат от персонализирано действие е лесно. Просто ще трябва да разширите интерфейса IHttpActionResult и след това да внедрите своя собствена версия на метода ExecuteAsync.