Mina två cent på att använda IHttpActionResult-gränssnittet i WebAPI

Microsofts WebAPI har under ganska lång tid varit ramarna för valet för att bygga RESTful-tjänster som kan fungera via HTTP. IHttpActionResult-gränssnittet har introducerats med WebAPI version 2 och ger ett annat sätt att skicka tillbaka svar från dina WebAPI-kontrollmetoder, och det utnyttjar asynkronisering och väntar som standard.

I huvudsak är IHttpActionResult en fabrik för HttpResponsemessage. IHttpActionResult-gränssnittet finns i System.Web.Http-namnområdet och skapar en instans av HttpResponseMessage asynkront. IHttpActionResult består av en samling anpassade inbyggda svar som inkluderar: Ok, BadRequest, Exception, Conflict, Redirect, NotFound och Oautoriserad.

IHttpActionResult-gränssnittet innehåller bara en metod. Så här ser det här gränssnittet ut:

namespace System.Web.Http

{

    public interface IHttpActionResult

    {

        Task ExecuteAsync(CancellationToken cancellationToken);

    }

}

Du kan returnera ett anpassat svar med hjälp av någon av hjälparmetoderna i ApiController-klassen som anges nedan.

Ok

NotFound

Exception

Unauthorized

BadRequest

Conflict

Redirect

InvalidModelState

Återkommande svar från WebAPI-styrningsmetoder

I det här avsnittet kommer vi att undersöka hur vi kan använda IHttpActionResult för att skicka tillbaka svar från styrenhetsmetoderna.

Tänk på följande WebApi-kontroller:

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

        }

    }

Observera att lämplig statuskod returneras i varje fall, dvs. om data är tillgängliga returneras HttpStatusCode.OK medan HttpStatusCode.NotFound returneras om data inte är tillgängliga.

Låt oss nu se hur samma styrmetod kan ändras för att returnera svaret som IHttpActionResult. Här är den uppdaterade koden för styrenhetsmetoden för din referens. Observera hur HttpResponseMessage har ersatts med IHttpActionResult.

public IHttpActionResult Get(int id)

        {

            var result = repository.GetData(id);

            if (result == null)

                return NotFound();

            return Ok(result);

        }

Se Get-metoden ovan. Koden är mycket enkel och mager och den abstrakt hur Http-meddelandet faktiskt är konstruerat i styrenheten. Och här är ett annat exempel.

Se följande kodavsnitt som returnerar HttpResponseMessage för att rapportera framgång eller misslyckande.

public HttpResponseMessage Delete(int id)

        {

            var status = repository.Delete(id);

            if (status)

               return new HttpResponseMessage(HttpStatusCode.OK);

            return new HttpResponseMessage(HttpStatusCode.NotFound);

        }

Se nu hur samma åtgärdsmetod kan omformuleras med IHttpActionResult för att göra koden mycket mager och enkel.

public IHttpActionResult Delete(int id)

        {

            var status = repository.Delete(id);

            if (status)

              return Ok();

            return NotFound();

        }

Vilken ska jag använda och varför?

Så ska vi använda IHttpActionResult över HttpResponseMessage i våra WebAPI-kontroller när vi skickar tillbaka svaren? Här är mitt svar på den här frågan. Jag skulle alltid föredra IHttpActionResult framför HttpResponseMessage, eftersom enhetstestning av styrenheterna skulle bli förenklade. Du kan flytta den vanliga logiken för att skapa Http-svar till andra klasser och göra dina styrenhetsmetoder magra och enkla. I grund och botten skulle detaljerna på låg nivå för att skapa Http-svar inkapslas.

På en annan anteckning är det värt att nämna att när du använder IHttpActionResult kan du följa principen om enskilt ansvar såväl som dina handlingsmetoder kan fokusera på att hantera Http-förfrågningar snarare än att konstruera Http-svarsmeddelanden. Det finns en annan punkt som är värt att nämna. Du kan dra nytta av IHttpActionResult för att ge stöd för HTML med Razor. Allt du behöver göra är att skapa ett anpassat åtgärdsresultat som kan analysera Razor-vyer. Att skapa ett anpassat åtgärdsresultat är enkelt. Du behöver bara utvidga gränssnittet IHttpActionResult och sedan implementera din egen version av ExecuteAsync-metoden.