Programmering

Mine to cent på brug af IHttpActionResult-grænsefladen i WebAPI

Microsofts WebAPI har i nogen tid været den valgte ramme til opbygning af RESTful-tjenester, der kan arbejde via HTTP. IHttpActionResult-grænsefladen er introduceret med WebAPI version 2 og giver en anden måde at sende svar tilbage fra dine WebAPI-controller-metoder, og den udnytter asynkronisering og afventer som standard.

I det væsentlige er IHttpActionResult en fabrik til HttpResponsemessage. IHttpActionResult-grænsefladen er indeholdt i System.Web.Http-navneområdet og opretter en forekomst af HttpResponseMessage asynkront. IHttpActionResult består af en samling af brugerdefinerede indbyggede svar, der inkluderer: Ok, BadRequest, Undtagelse, Konflikt, Omdirigering, NotFound og Uautoriseret.

IHttpActionResult-grænsefladen indeholder kun en metode. Sådan ser denne grænseflade ud:

navneområde System.Web.Http

{

offentlig grænseflade IHttpActionResult

    {

Task ExecuteAsync (CancellationToken cancellationToken);

    }

}

Du kan returnere et brugerdefineret svar ved hjælp af en af ​​hjælpemetoderne i ApiController-klassen, der er anført nedenfor.

Okay

Ikke fundet

Undtagelse

Uberettiget

Dårlig anmodning

Konflikt

Omdiriger

InvalidModelState

Tilbagevendende svar fra WebAPI-controller-metoder

I dette afsnit vil vi undersøge, hvordan vi kan udnytte IHttpActionResult til at sende svar tilbage fra controller-metoderne.

Overvej nu følgende WebApi-controller:

offentlig klasse DefaultController: ApiController

    {

privat readonly DemoRepository repository = nyt DemoRepository ();

offentlig HttpResponseMessage Get (int id)

        {

var resultat = repository.GetData (id);

hvis (resultat! = null)

returner Request.CreateResponse (HttpStatusCode.OK, resultat);

returner Request.CreateResponse (HttpStatusCode.NotFound);

        }

    }

Bemærk, at den relevante statuskode returneres i hvert tilfælde, dvs. hvis data er tilgængelige, returneres HttpStatusCode.OK, mens HttpStatusCode.NotFound returneres, hvis data ikke er tilgængelige.

Lad os nu se, hvordan den samme controller-metode kan ændres for at returnere svaret som IHttpActionResult. Her er den opdaterede kode for controller-metoden til din reference. Bemærk, hvordan HttpResponseMessage er blevet erstattet med IHttpActionResult.

offentlig IHttpActionResult Get (int id)

        {

var resultat = repository.GetData (id);

hvis (resultat == null)

returner NotFound ();

returner Ok (resultat);

        }

Se Get-metoden ovenfor. Koden er meget enkel og slank, og den opsummerer den måde, hvorpå Http-meddelelsen faktisk er konstrueret i controlleren. Og her er et andet eksempel.

Henvis til følgende kodestykke, der returnerer HttpResponseMessage for at rapportere succes eller fiasko.

public HttpResponseMessage Delete (int id)

        {

var status = repository.Delete (id);

hvis (status)

returner nyt HttpResponseMessage (HttpStatusCode.OK);

returner nyt HttpResponseMessage (HttpStatusCode.NotFound);

        }

Se nu, hvordan den samme handlingsmetode kan omformuleres ved hjælp af IHttpActionResult for at gøre koden meget mere slank og enkel.

offentlig IHttpActionResult Slet (int id)

        {

var status = repository.Delete (id);

hvis (status)

returner Ok ();

returner NotFound ();

        }

Hvilken skal jeg bruge, og hvorfor?

Så skal vi bruge IHttpActionResult over HttpResponseMessage i vores WebAPI-controllere, når vi sender svarene tilbage? Her er mit svar på dette spørgsmål. Jeg foretrækker altid IHttpActionResult frem for HttpResponseMessage, da enhedstestning af controllerne bliver forenklet. Du kan flytte den fælles logik til oprettelse af Http-svar til andre klasser og gøre dine controller-metoder slanke og enkle. I det væsentlige ville detaljerne på lavt niveau ved oprettelse af Http-svarene være indkapslet.

På en anden note er det værd at nævne, at når du bruger IHttpActionResult, kan du overholde Single Responsibility Princippet, såvel som dine handlingsmetoder kan fokusere på håndtering af Http-anmodninger snarere end at konstruere Http-svarmeddelelser. Der er et andet punkt, der er værd at nævne. Du kan drage fordel af IHttpActionResult for at yde support til HTML med Razor. Alt hvad du skal gøre er at oprette et brugerdefineret handlingsresultat, der kan analysere Razor-visninger. Oprettelse af et brugerdefineret handlingsresultat er enkelt. Du skal bare udvide IHttpActionResult-grænsefladen og derefter implementere din egen version af ExecuteAsync-metoden.

$config[zx-auto] not found$config[zx-overlay] not found