Microsoftin WebAPI on jo jonkin aikaa ollut valintakehys RESTful-palvelujen rakentamiseen, jotka voivat toimia HTTP: n kautta. IHttpActionResult-käyttöliittymä on otettu käyttöön WebAPI-version 2 kanssa ja tarjoaa eri tavan lähettää vastauksia WebAPI-ohjaimen menetelmistä, ja se hyödyntää asynkronointia ja odottaa oletuksena.
Pohjimmiltaan IHttpActionResult on HttpResponsemessagen tehdas. IHttpActionResult-liitäntä sisältyy System.Web.Http-nimitilaan ja luo HttpResponseMessage-esiintymän asynkronisesti. IHttpActionResult sisältää kokoelman mukautettuja sisäänrakennettuja vastauksia, jotka sisältävät: Ok, BadRequest, Exception, Conflict, Redirect, NotFound ja Luvattomat.
IHttpActionResult-käyttöliittymä sisältää vain yhden menetelmän. Näin tämä käyttöliittymä näyttää:
nimitila System.Web.Http
{
julkinen käyttöliittymä IHttpActionResult
{
Tehtävä ExecuteAsync (CancellationToken cancellationToken);
}
}
Voit palauttaa mukautetun vastauksen jollakin alla luetelluista ApiController-luokan apumenetelmistä.
Ok
Ei löydetty
Poikkeus
Luvaton
BadRequest
Konflikti
Ohjaa uudelleen
InvalidModelState
Palautetaan vastaus WebAPI-ohjaimen menetelmistä
Tässä osiossa tutkitaan, kuinka voimme hyödyntää IHttpActionResult -toimintoa palauttaaksemme vastauksia ohjaimen menetelmistä.
Harkitse nyt seuraavaa WebApi-ohjainta:
public class DefaultController: ApiController
{
private readonly DemoRepository repository = uusi DemoRepository ();
public HttpResponseMessage Get (int id)
{
var tulos = arkisto.GetData (id);
jos (tulos! = nolla)
return Request.CreateResponse (HttpStatusCode.OK, tulos);
return Request.CreateResponse (HttpStatusCode.NotFound);
}
}
Huomaa, että asianmukainen tilakoodi palautetaan kussakin tapauksessa, ts. Jos tietoja on saatavilla, HttpStatusCode.OK palautetaan, kun taas HttpStatusCode.NotFound palautetaan, jos tietoja ei ole saatavilla.
Katsotaan nyt, kuinka samaa ohjaimen menetelmää voidaan muuttaa vastauksen palauttamiseksi kuin IHttpActionResult. Tässä on päivitetty ohjaimen menetelmän koodi viitteellesi. Huomaa, kuinka HttpResponseMessage on korvattu IHttpActionResultilla.
public IHttpActionResult Get (int id)
{
var result = arkisto.GetData (id);
jos (tulos == nolla)
return Ei löydy ();
palaa Ok (tulos);
}
Katso yllä annettu Get-menetelmä. Koodi on paljon yksinkertainen ja laiha ja se tiivistää tavan, jolla Http-viesti todella rakennetaan ohjaimessa. Ja tässä on toinen esimerkki.
Raportoi onnistumisesta tai epäonnistumisesta seuraavasta koodinpätkästä, joka palauttaa HttpResponseMessage.
public HttpResponseMessage Delete (int id)
{
var status = arkisto.Poista (id);
jos (tila)
palauta uusi HttpResponseMessage (HttpStatusCode.OK);
palauta uusi HttpResponseMessage (HttpStatusCode.NotFound);
}
Katso nyt, kuinka sama toimintamenetelmä voidaan korjata IHttpActionResult-toiminnolla, jotta koodista tulee paljon kevyempi ja yksinkertaisempi.
public IHttpActionResult Poista (int id)
{
var status = arkisto.Poista (id);
jos (tila)
palaa Ok ();
return Ei löydy ();
}
Mitä minun pitäisi käyttää ja miksi?
Pitäisikö meidän siis käyttää IHttpActionResult yli HttpResponseMessage WebAPI-ohjaimissamme, kun lähetämme vastauksia? Tässä on vastaukseni tähän kysymykseen. Haluaisin aina mieluummin IHttpActionResultin kuin HttpResponseMessage, koska näin tehtäessä ohjainten yksikkötestaus yksinkertaistuu. Voit siirtää yleisen logiikan Http-vastausten luomiseen muihin luokkiin ja tehdä ohjaimen menetelmästä kevyt ja yksinkertainen. Pohjimmiltaan Http-vastausten luomisen matalat yksityiskohdat olisi kapseloitu.
Toisessa huomautuksessa on syytä mainita, että käyttämällä IHttpActionResult -ohjelmaa voit noudattaa yhden vastuun periaatetta ja toimintamenetelmät voivat keskittyä Http-pyyntöjen käsittelyyn Http-vastausviestien rakentamisen sijaan. On vielä yksi mainitsemisen arvoinen seikka. Voit käyttää IHttpActionResult-ohjelmaa tarjotaksesi HTML-tuen Razorilla. Sinun tarvitsee vain luoda mukautettu toimintatulos, joka voi jäsentää Razor-näkymät. Mukautetun toimintatuloksen luominen on helppoa. Sinun tarvitsee vain laajentaa IHttpActionResult-käyttöliittymää ja ottaa sitten käyttöön oma versio ExecuteAsync-menetelmästä.
