Share
ASP.NET Web API is een framework voor het bouwen van web-API's bovenop het .NET Framework dat gebruik maakt van HTTP. Aangezien bijna elk platform dat u kunt bedenken een HTTP-bibliotheek heeft, kunnen HTTP-services worden gebruikt door een breed scala aan clients, waaronder browsers, mobiele apparaten en traditionele desktoptoepassingen..
ASP.NET Web API maakt gebruik van de concepten van HTTP en biedt functies zoals:
Voor het maken van een web-API gebruiken we Visual Studio. Als je Visual Studio 2012 of een hogere versie hebt, dan ben je helemaal goed om te beginnen met je Web API.
Van de het dossier menu, selecteer nieuwe en dan project.
In de templates deelvenster, selecteer Geïnstalleerde sjablonen en breid het uit Visual C # knooppunt. Onder Visual C #, kiezen Web. Selecteer in de lijst met projectsjablonen ASP.NET-webapplicatie. Stel de naam van uw voorkeur in voor het project en klik OK.
In het volgende venster krijgt u een lijst met sjablonen te zien. Hoewel u een van de sjablonen uit de lijst kunt selecteren omdat ze allemaal DLL-bestanden en configuraties bevatten die nodig zijn om Web API-controllers te maken, selecteren we de Leeg project Sjabloon om mee te beginnen.
In Web API, a controleur is een object dat HTTP-aanvragen afhandelt. Laten we snel een controller toevoegen voor het testen van onze web-API.
In Solution Explorer, klik met de rechtermuisknop op de Controllers map. kiezen Toevoegen en selecteer vervolgens controleur. We zullen de controller bellen TestController en selecteer Lege API-controller van de Scaffolding-opties voor Template.
Visual Studio maakt onze controller afgeleid van de ApiController klasse. Laten we hier een snelle functie toevoegen om ons API-project te testen door het te hosten IIS.
openbaar IEnumerableGet () return new string [] "hallo", "wereld";
Nu voegen we onze service toe aan IIS zodat we er lokaal toegang toe hebben. Open IIS en klik met de rechtermuisknop op Standaard website om onze webservice toe te voegen.
In de Applicatie toevoegen dialoogvenster, geef uw service een naam TestAPI en geef een pad naar het rootpad van het Visual Studio-project, zoals hieronder weergegeven.
Klik OK en onze Web API Service is klaar.
Om te testen of alles goed werkt, proberen we de volgende URL in elke browser: http: // localhost / TestAPI / api / test.
Als u uw controller een naam hebt gegeven TestController zoals ik heb en noemde ook uw webservice in IIS als TestAPI dan moet uw browser een XML-bestand retourneren zoals hieronder getoond met stringwaarden Hallo Wereld.
Als uw IIS echter geen toestemming heeft voor de projectmap, krijgt u mogelijk een foutbericht met de melding: "De gevraagde pagina is niet toegankelijk omdat de gerelateerde configuratiegegevens voor de pagina ongeldig zijn. "
Als u dit type fout krijgt, kunt u dit oplossen door lees- / schrijftoegang tot de. Te geven IIS_IUSRS gebruikersgroep naar de hoofdmap.
Laten we nu eens kijken hoe de URL die we aan de browser hebben verstrekt werkt.
ASP.NET Routing verwerkt het proces van het ontvangen van een aanvraag en wijst het toe aan een controlleractie. Web API-routering is vergelijkbaar met MVC-routering maar met enkele verschillen; Web API gebruikt het HTTP-verzoektype in plaats van de actienaam in de URL (zoals in het geval van MVC) om de actie te selecteren die moet worden uitgevoerd in de controller.
De routeringsconfiguratie voor Web API wordt in het bestand gedefinieerd WebApiConfig.cs. De standaard routeringsconfiguratie van de ASP.NET Web API is zoals hieronder getoond:
openbare statische klasse WebApiConfig public static void Register (HttpConfiguration config) config.Routes.MapHttpRoute (naam: "DefaultApi", routeTemplate: "api / controller / id", standaardwaarden: nieuw id = RouteParameter.Optioneel );
Het standaardrouteringssjabloon van Web API is api / controller / id. Dat is waarom we hadden "api"in onze URL http: // localhost / TestAPI /api/test.
Wanneer Web API een GET-aanvraag voor een bepaalde controller ontvangt, zijn de lijst met overeenkomende acties allemaal methoden waarvan de naam begint met GET. Hetzelfde is het geval met alle andere HTTP-werkwoorden. De juiste actiewerkwijze die moet worden opgeroepen, wordt geïdentificeerd door de handtekening van de methode te vergelijken.
Deze naamconventie voor actiemethoden kan worden overschreven door de HttpGet,
HttpPut, HttpPost, of HttpDelete attributen met de actiemethoden.
Dus als we onze vorige code vervangen door deze:
[HttpGet] public IEnumerableHallo () retourneer nieuwe tekenreeks [] "hallo", "wereld";
En druk op http: // localhost / TestAPI /api/ test in onze browser, zal dit nog steeds hetzelfde resultaat opleveren. Als we het verwijderen HttpGet kenmerk, onze Web API kan geen overeenkomende actie vinden voor ons verzoek.
Laten we nu een andere methode met dezelfde naam toevoegen Hallo maar met een andere handtekening.
[HttpGet] public IEnumerableHallo (tekenreeks-ID) plaats een nieuwe tekenreeks [] id, "world";
Met behulp van deze methode kunnen we nu bepalen wat er uit onze Service wordt teruggestuurd. Als we deze methode testen door http: // localhost / TestAPI / api / test / namaste aan te roepen (zie een extra parameter aan het einde van de URL), krijgen we de volgende uitvoer:
Dus nu hebben we twee methoden genoemd Hallo. Men neemt geen parameters en geeft tekenreeksen "hallo wereld", en een andere methode neemt één parameter en geeft als resultaat "yourparameter wereld".
Hoewel we niet de naam hebben opgegeven van onze methode die moet worden uitgevoerd in onze URL, begrijpt de standaard ASP.NET-routering de aanvraag als een GET-aanvraag en op basis van de handtekening van de aanvraag (opgegeven parameters), wordt de specifieke methode uitgevoerd. Dit is prima als we maar één GET- of POST-methode hebben in onze controller, maar omdat in een echte bedrijfsapplicatie er meestal meer dan één zo'n GET-methode is, is deze standaardroutering niet voldoende.
Laten we nog een GET-methode toevoegen om te zien hoe de standaardroutering dit verwerkt.
[HttpGet] public IEnumerableGoodBye () return new string [] "tot ziens", "world";
Als we ons project nu bouwen en http: // localhost / TestAPI / api / test / in onze browser bellen, krijgen we een foutmelding die zegt:Er zijn meerdere acties gevonden die overeenkomen met het verzoek", wat betekent dat het routingsysteem twee acties identificeert die overeenkomen met het GET-verzoek.
Om meerdere GET-verzoeken van dezelfde controller te kunnen gebruiken, moeten we de HTTP-aanvraagtypen-ID wijzigen met een actiegebaseerde ID zodat meerdere GET-aanvragen kunnen worden aangeroepen.
Dit kan gedaan worden door de volgende routeconfiguratie toe te voegen voor de standaardconfiguratie in WebApiConfig.cs.
config.Routes.MapHttpRoute (naam: "DefaultApi2", routeTemplate: "api / controller / action / id", standaardwaarden: nieuw id = RouteParameter.Optioneel);
Test nu alle drie methoden door deze URL's te bellen:
Nu wordt het basisidee van hoe acties van controllers via de API kunnen worden blootgesteld begrepen, laten we eens kijken hoe een API-service voor klanten kan worden ontworpen.
De ASP.NET Web API-verzoekpijplijn ontvangt aanvragen van de clienttoepassing en een actiemethode in een controller wordt aangeroepen. De actiemethode roept op zijn beurt de bedrijfslaag in voor het ophalen of bijwerken van gegevens, die op zijn beurt de repositoryklasse aanroept om gegevens uit de database te retourneren.
Op basis van dit ontwerppatroon maken we een voorbeeld-API die een lijst met geclassificeerde items als een service voor zijn klanten weergeeft.
Maak een klasse genaamd ClassifiedModel binnen in de modellen map.
public class ClassifiedModel public int ClassifiedID get; vast te stellen; public string ClassifiedTitle get; vast te stellen; openbare tekenreeks ClassifiedDetail get; vast te stellen; public DateTime CreatedDate get; vast te stellen; openbare tekenreeks ClassifiedImage get; vast te stellen;
Maak twee mappen BLL en DAL de Business Logic Layer en Data Access Layer vertegenwoordigen.
Maak een klasse genaamd ClassifiedRepository binnen in de DAL map waarin we sommige gegevens hard coderen voor de geclassificeerde lijst en de lijst via een statische methode weergeven.
openbare klasse ClassifiedRepository // lijst met openbare statische lijst met objectenclassifiedList; /// /// krijg lijst met geclassificeerde modellen /// ///openbare statische lijst GetClassifiedsList () if (classifiedList == null || classifiedList.Count == 0) CreateClassifiedsList (); return classifiedList; /// /// Een lijst met geclassificeerde items openen /// private static void CreateClassifiedsList () classifiedList = new List() nieuw ClassifiedModel () ClassifiedID = 1, ClassifiedTitle = "Auto te koop", ClassifiedDetail = "Autodetails car details car details", CreatedDate = DateTime.Now, ClassifiedImage = "/carImageUrl.jpg", nieuw ClassifiedModel ( ) ClassifiedID = 2, ClassifiedTitle = "Huis uitverkoop", ClassifiedDetail = "Huis details huis details huis details", CreatedDate = DateTime.Now, ClassifiedImage = "/houseImageUrl.jpg", nieuw ClassifiedModel () ClassifiedID = 3, ClassifiedTitle = "Kamer te huur", ClassifiedDetail = "Kamer details kamer details kamer details", CreatedDate = DateTime.Now, ClassifiedImage = "/roomImageUrl.jpg", nieuw ClassifiedModel () ClassifiedID = 4, ClassifiedTitle = "Boom te koop ", ClassifiedDetail =" Boom details boom details boom details ", CreatedDate = DateTime.Now, ClassifiedImage =" /treeImageUrl.jpg ";
Laten we nog een klas toevoegen ClassifiedService binnen in de BLL map nu. Deze klasse bevat een statische methode om toegang te krijgen tot de repository en bedrijfsobjecten terug te sturen naar de controller. Op basis van de zoekparameters retourneert de methode de lijst met geclassificeerde items.
public class ClassifiedService public static ListGetClassifieds (string searchQuery) var classifiedList = ClassifiedRepository.GetClassifiedsList (); if (! string.IsNullOrEmpty (searchQuery)) return (van m in classifiedList waarbij m.ClassifiedTitle.StartsWith (searchQuery, StringComparison.CurrentCultureIgnoreCase) select m) .ToList (); return classifiedList;
Ten slotte zullen we nu onze Web API-controller maken voor de geclassificeerde lijstgerelateerde methoden.
Vergelijkbaar met hoe we onze eerste hebben gemaakt TestController, laten we een API-controller maken met lege lees- / schrijfacties genaamd ClassifiedsController en voeg de volgende twee actiemethoden toe.
public class ClassifiedsController: ApiController public ListGet (string id) ga naar ClassifiedService.GetClassifieds (id); openbare lijst Get () return ClassifiedService.GetClassifieds ("");
Nu hebben we twee acties die worden weergegeven via de API. De eerste GET-methode wordt aangeroepen als er een sleutelwoord moet worden doorzocht dat samen met het verzoek wordt doorgegeven. Als er geen invoerparameter is, wordt de tweede GET-methode aangeroepen. Beide methoden retourneren een lijst met onze gerubriceerde modelobjecten.
Vergeet niet om alle vereiste verwijzingen naar de naamruimten in elk van de toegevoegde klassenbestanden toe te voegen. Bouw het project en we zijn nu klaar om beide methoden te testen.
Om resultaten weer te geven die de zoekparameter bevatten "huis", klik op de volgende URL in de browser: http: // localhost / TestAPI / api / classifieds / get / house.
We zouden de volgende reactie in de browser moeten krijgen:
Om de volledige lijst met advertenties te zien, klik op de URL zonder parameters door te geven: http: // localhost / TestAPI / api / classifieds / get /.
Je zou het volgende resultaat moeten zien:
We kunnen een willekeurig aantal acties en controllers toevoegen op dezelfde manier als gewenst door de clients.
Tot nu toe hebben we voorbeelden gezien van API die XML-antwoorden naar de clients verzenden. Laten we nu kijken naar andere inhoudstypen zoals JSON en Image-reactie, die vallen onder het onderwerp Inhoudonderhandeling.
De HTTP-specificatie (RFC 2616) definieert inhoudsbemiddeling als "het proces van het selecteren van de beste representatie voor een bepaald antwoord wanneer er meerdere representaties beschikbaar zijn."Dankzij de Content Negotiation-functie van Web API kunnen klanten Web API-services vertellen welke contentindeling ze accepteren en kan Web API de client automatisch van dezelfde indeling voorzien, mits de indeling is geconfigureerd in Web API.
De HTTP Accept-header wordt gebruikt om de mediatypes te specificeren die aanvaardbaar zijn voor de
klant voor de antwoorden. Voor XML is de waarde ingesteld als "application / xmlen voor JSON "Application / json".
Om onze API te testen met de HTTP Accept-headers, kunnen we de extensies gebruiken die beschikbaar zijn voor de browsers waarmee we aangepaste HTTP-verzoeken kunnen maken.
Hier gebruik ik een extensie genaamd HTTP-tool beschikbaar voor Mozilla Firefox om de Accept-header te maken die JSON als responstype aangeeft.
Zoals u kunt zien in de afbeelding, is het antwoord dat wordt ontvangen in JSON-indeling.
Laten we tot slot zien hoe we een afbeeldingsbestand kunnen verzenden als een reactie via de web-API.
Laten we een map maken met de naam Afbeeldingen en voeg een afbeelding toe met de naam "default.jpg"erin en voeg dan de volgende Action-methode toe aan onze ClassifiedsController.
Accentsconagua
public HttpResponseMessage GetImage () byte [] bytes = System.IO.File .ReadAllBytes (HttpContext.Current.Server .MapPath ("~ / Images / default.jpg")); var result = new HttpResponseMessage (HttpStatusCode.OK); result.Content = new ByteArrayContent (bytes); result.Content.Headers.ContentType = nieuwe MediaTypeHeaderValue ("image / png"); terugkeer resultaat; Ook moeten deze twee naamruimten worden opgenomen: System.Web, System.Web.Http.
Hier creëren we een HTTP-antwoord met behulp van de HttpResponseMessage klasse en het instellen van de afbeeldingbytes als antwoordinhoud. Ook stellen we de Content-Type koptekst naar "image / png".
Nu, als we deze actie in onze browser noemen, verzendt Web API onze default.jpg afbeelding als reactie: http: // localhost / TestAPI / api / classifieds / Getimage /.
In deze zelfstudie hebben we gekeken hoe ASP.NET Web API eenvoudig kan worden gemaakt en aan clients kan worden getoond als Action-methoden van MVC-controllers. We hebben gekeken naar het standaard en aangepaste routingsysteem, de basisstructuur van een realtime API voor bedrijfsapplicaties gemaakt en ook gekeken naar verschillende antwoordtypen.
En als u op zoek bent naar een aantal extra hulpprogramma's om het .NET-aanbod in CodeCanyon aan te schaffen, te bekijken of te gebruiken.
Ik hoop dat je deze tutorial leuk vond en vond het nuttig voor het bouwen van je web-API's voor mobiele apparaten. Bedankt!
