Microsofts WebAPI har i lang tid vært rammen for valg for å bygge RESTful-tjenester som kan fungere over HTTP. IHttpActionResult-grensesnittet har blitt introdusert med WebAPI versjon 2 og gir en annen måte å sende svar fra WebAPI-kontrollermetodene dine, og den utnytter asynkronisering og venter som standard.
I hovedsak er IHttpActionResult en fabrikk for HttpResponsemessage. IHttpActionResult-grensesnittet finnes i navneområdet for System.Web.Http og oppretter en forekomst av HttpResponseMessage asynkront. IHttpActionResult består av en samling tilpassede innebygde svar som inkluderer: Ok, BadRequest, Exception, Conflict, Redirect, NotFound og Uautorized.
IHttpActionResult-grensesnittet inneholder bare en metode. Slik ser dette grensesnittet ut:
navneområde System.Web.Http
{
offentlig grensesnitt IHttpActionResult
{
Task ExecuteAsync (CancellationToken cancellationToken);
}
}
Du kan returnere et tilpasset svar ved hjelp av noen av hjelpermetodene i ApiController-klassen som er oppført nedenfor.
Ok
Ikke funnet
Unntak
Uautorisert
Dårlig forespørsel
Konflikt
Viderekobling
InvalidModelState
Returnerer respons fra WebAPI-kontrollermetoder
I denne delen vil vi undersøke hvordan vi kan utnytte IHttpActionResult for å sende tilbake svar fra kontrollermetodene.
Vurder nå følgende WebApi-kontroller:
offentlig klasse DefaultController: ApiController
{
privat readonly DemoRepository repository = nytt 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);
}
}
Merk at riktig statuskode returneres i hvert tilfelle, dvs. hvis data er tilgjengelige, returneres HttpStatusCode.OK mens HttpStatusCode.NotFound returneres hvis data ikke er tilgjengelige.
La oss nå se hvordan den samme kontrollermetoden kan endres for å returnere svaret som IHttpActionResult. Her er den oppdaterte koden for kontrollermetoden som referanse. Legg merke til hvordan HttpResponseMessage er erstattet med IHttpActionResult.
offentlig IHttpActionResult Get (int id)
{
var result = repository.GetData (id);
hvis (resultat == null)
returner NotFound ();
returner Ok (resultat);
}
Se Get-metoden gitt ovenfor. Koden er mye enkel og slank, og den abstrakte måten Http-meldingen faktisk er konstruert i kontrolleren. Og her er et annet eksempel.
Henvis til følgende kodebit som returnerer HttpResponseMessage for å rapportere suksess eller fiasko.
public HttpResponseMessage Delete (int id)
{
var status = repository.Delete (id);
hvis (status)
returner nye HttpResponseMessage (HttpStatusCode.OK);
returner nye HttpResponseMessage (HttpStatusCode.NotFound);
}
Se nå hvordan den samme handlingsmetoden kan omformuleres ved hjelp av IHttpActionResult for å gjøre koden mye mer slank og enkel.
offentlig IHttpActionResult Slett (int id)
{
var status = repository.Delete (id);
hvis (status)
returner Ok ();
returner NotFound ();
}
Hvilken bør jeg bruke og hvorfor?
Så skal vi bruke IHttpActionResult over HttpResponseMessage i WebAPI-kontrollerne når vi sender svarene tilbake? Her er svaret mitt på dette spørsmålet. Jeg foretrekker alltid IHttpActionResult fremfor HttpResponseMessage som ved å gjøre det, vil enhetstesting av kontrollerne bli forenklet. Du kan flytte den vanlige logikken for å lage Http-svar til andre klasser og gjøre kontrollermetodene dine magre og enkle. I det vesentlige vil de lave detaljene for å lage Http-svarene være innkapslet.
På et annet notat er det verdt å nevne at når du bruker IHttpActionResult, kan du følge Single Responsibility Principle, i tillegg til at dine handlingsmetoder kan fokusere på å håndtere Http-forespørslene i stedet for å konstruere Http-svarmeldingene. Det er et annet poeng det er verdt å nevne. Du kan dra nytte av IHttpActionResult for å gi støtte for HTML med Razor. Alt du trenger å gjøre er å lage et tilpasset handlingsresultat som kan analysere Razor-visninger. Å lage et tilpasset handlingsresultat er enkelt. Du trenger bare å utvide IHttpActionResult-grensesnittet og deretter implementere din egen versjon av ExecuteAsync-metoden.
