Programiranje

Moja dva centa za uporabo vmesnika IHttpActionResult v WebAPI

Microsoftov WebAPI je že nekaj časa okvir izbire za izdelavo RESTful storitev, ki lahko delujejo prek HTTP. Vmesnik IHttpActionResult je bil predstavljen z različico WebAPI 2 in ponuja drugačen način za pošiljanje odgovorov iz metod krmilnika WebAPI, privzeto pa uporablja asinhronizacijo in čakanje.

V bistvu je IHttpActionResult tovarna za HttpResponsemessage. Vmesnik IHttpActionResult je vsebovan v imenskem prostoru System.Web.Http in asinhrono ustvari primerek HttpResponseMessage. IHttpActionResult vsebuje zbirko vgrajenih odzivov po meri, ki vključujejo: Ok, BadRequest, Exception, Conflict, Redirect, NotFound in Unauthorized.

Vmesnik IHttpActionResult vsebuje samo eno metodo. Ta vmesnik je videti tako:

imenski prostor System.Web.Http

{

javni vmesnik IHttpActionResult

    {

Task ExecuteAsync (CancellationToken cancellationToken);

    }

}

Odziv po meri lahko vrnete s katero koli od pomožnih metod razreda ApiController, navedenih spodaj.

V redu

Ni najdeno

Izjema

Nepooblaščeno

Slaba prošnja

Konflikt

Preusmeritev

InvalidModelState

Vrnitev odziva iz metod krmilnika WebAPI

V tem poglavju bomo raziskali, kako lahko uporabimo IHttpActionResult za pošiljanje odgovorov iz metod krmilnika.

Zdaj razmislite o naslednjem krmilniku WebApi:

javni razred DefaultController: ApiController

    {

zasebno repozitorij DemoRepository samo za branje = novo DemoRepository ();

public HttpResponseMessage Get (int id)

        {

var rezultat = repozitorij.GetData (id);

če (rezultat! = nič)

vrni Request.CreateResponse (HttpStatusCode.OK, rezultat);

vrni Request.CreateResponse (HttpStatusCode.NotFound);

        }

    }

Upoštevajte, da se v vsakem primeru vrne ustrezna koda stanja, tj. Če so podatki na voljo, se vrne HttpStatusCode.OK, medtem ko se HttpStatusCode.NotFound vrne, če podatki niso na voljo.

Poglejmo zdaj, kako je mogoče isto metodo krmilnika spremeniti, da vrne odziv kot IHttpActionResult. Tu je posodobljena koda metode krmilnika za vašo referenco. Upoštevajte, kako je bil HttpResponseMessage nadomeščen z IHttpActionResult.

public IHttpActionResult Get (int id)

        {

var rezultat = repozitorij.GetData (id);

če (rezultat == null)

vrni NotFound ();

vrni Ok (rezultat);

        }

Glejte zgoraj navedeno metodo Get. Koda je precej preprosta in vitka ter povzema način, kako je v krmilniku dejansko zgrajeno sporočilo Http. In tukaj je še en primer.

Za poročanje o uspehu ali neuspehu glejte naslednji delček kode, ki vrne HttpResponseMessage.

public HttpResponseMessage Delete (int id)

        {

var status = repozitorij.Delete (id);

če (status)

vrni novo HttpResponseMessage (HttpStatusCode.OK);

vrni novo HttpResponseMessage (HttpStatusCode.NotFound);

        }

Zdaj pa poglejte, kako je mogoče isto metodo akcije spremeniti z uporabo IHttpActionResult, da bo koda veliko bolj vitka in enostavna.

public IHttpActionResult Delete (int id)

        {

var status = repozitorij.Delete (id);

če (status)

vrni Ok ();

vrni NotFound ();

        }

Katero naj uporabim in zakaj?

Ali bi torej morali uporabiti IHttpActionResult prek HttpResponseMessage v naših krmilnikih WebAPI, ko pošiljamo odgovore nazaj? Tukaj je moj odgovor na to vprašanje. Vedno bi raje imel IHttpActionResult kot HttpResponseMessage, saj bi pri tem enotno testiranje krmilnikov postalo poenostavljeno. Skupno logiko za ustvarjanje odzivov Http lahko premaknete v druge razrede in naredite metode krmilnika vitkejše in preprostejše. V bistvu bi bile vključene podrobnosti o nizki ravni ustvarjanja odzivov Http.

Pri drugi opombi velja omeniti, da se lahko pri uporabi IHttpActionResult držite načela enotne odgovornosti, prav tako pa se lahko vaše metode delovanja osredotočijo na obdelavo zahtev Http in ne na izdelavo sporočil Http. Omeniti velja še eno točko. IHttpActionResult lahko izkoristite za podporo HTML-ju z Razorjem. Vse, kar morate storiti, je ustvariti rezultat dejanja po meri, ki lahko razčleni poglede Razor. Ustvarjanje rezultata dejanja po meri je preprosto. Morali bi samo razširiti vmesnik IHttpActionResult in nato implementirati svojo različico metode ExecuteAsync.

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