ASP.NET webapi Interview Questions
1.0.0
Klicken Sie, wenn Ihnen das Projekt gefällt. Pull Requests werden sehr geschätzt. Folgen Sie mir @kansiris87 für technische Updates.
| NEIN. | Fragen |
|---|---|
| 1 | [Was ist REST?](#Was ist REST?) |
| 2 | [REST-Prinzip erklären?](#REST-Prinzip erklären?) |
| 3 | [Was ist der Unterschied zwischen REST und SOAP?](#Was ist der Unterschied zwischen REST und SOAP?) |
| 4 | [Was ist die ASP.NET WEB-API?](#Was ist die ASP.NET WEB-API?) |
| 5 | [Warum ASP.NET WEB API wählen?](#Warum ASP.NET WEB API wählen?) |
| 6 | [Was ist der Unterschied zwischen WCF und ASP.NET WEB API und WCF REST und Web Service?](#Was ist der Unterschied zwischen WCF und ASP.NET WEB API und WCF REST und Web Service?) |
| 7 | [Welches soll man zwischen WCF und WEB-API wählen?](#Welches soll man zwischen WCF und WEB-API wählen?) |
| 8 | [Was ist der Unterschied zwischen ASP.NET MVC und ASP.NET WEB API?](#HWas ist der Unterschied zwischen ASP.NET MVC und ASP.NET WEB API?) |
| 9 | [Können Sie die Ansicht mithilfe der WEB-API-Methode zurückgeben?](#Können Sie die Ansicht mithilfe der WEB-API-Methode zurückgeben?) |
| 10 | [Können Sie den WEB-API-Aktionsnamen wie ASP.NET MVC ändern?](#Können Sie den WEB-API-Aktionsnamen wie ASP.NET MVC ändern?) |
|1 | [Können Sie den Aufruf einer WEB-API-Aktionsmethode nur durch HTTP GET, POST, PUT oder DELETE einschränken?](#Können Sie den Aufruf einer WEB-API-Aktionsmethode nur durch HTTP GET, POST, PUT oder DELETE einschränken?)| |2 | [Wie rufe ich die WEB-API in ASP.NET MVC auf?](#Wie rufe ich die WEB-API in ASP.NET MVC auf?)| |3 | [Wie unterscheidet sich das ASP.NET-API-Routing vom ASP.NET-MVC-Routing?](#Wie unterscheidet sich das ASP.NET-API-Routing vom ASP.NET-MVC-Routing?)| |4 | [Wie aktiviere ich das Attributrouting in ASP.NET WEB API2?](#Wie aktiviere ich das Attributrouting in ASP.NET WEB API2?)| |5 | [Wie definiere ich das Attributrouting in ASP.NET WEB API2?](#Wie definiere ich das Attributrouting in ASP.NET WEB API2?)|
REST steht für Representational State Transfer. Dies ist ein Protokoll zum Austausch von Daten über eine verteilte Umgebung. REST ist ein Architekturstil, der jeden Dienst als Ressource behandelt und über HTTP-Protokollmethoden wie GET, POST, PUT und DELETE auf Daten zugreift.
Architekturen im REST-Stil bestehen aus Clients und Servern. Clients initiieren Anfragen an Server, die diese Anfragen verarbeiten und auf der Grundlage dieser Anfragen Antworten zurücksenden. Diese Anfragen und Antworten basieren auf der Übertragung von Darstellungen dieser Ressourcen.
REST ist eine Reihe von Prinzipien, die definieren, wie Webstandards wie HTTP und URIs verwendet werden sollen. Es gibt fünf wichtige REST-Prinzipien, wie unten aufgeführt:
Adressierbare Ressourcen – Jede Ressource sollte durch einen URI (eindeutige Kennung) identifiziert werden.
Einfache und einheitliche Schnittstellen – REST basiert auf dem HTTP-Protokoll. Verwenden Sie daher die HTTP-Methoden GET, POST, PUT und DELETE, um Aktionen auszuführen. Dies macht REST einfach und einheitlich.
Repräsentationsorientiert – Repräsentationen von Ressourcen werden ausgetauscht. GET wird verwendet, um eine Darstellung zurückzugeben, und PUT, POST übergibt die Darstellung an den Server, sodass sich die zugrunde liegenden Ressourcen ändern können. Die Darstellung kann in vielen Formaten wie XML, JSON usw. erfolgen.
Zustandslos kommunizieren – Eine Anwendung hat möglicherweise einen Status, es sind jedoch keine Client-Sitzungsdaten auf dem Server gespeichert. Alle sitzungsspezifischen Daten sollten vom Client gespeichert und verwaltet und bei Bedarf bei jeder Anfrage an den Server übertragen werden.
Zwischenspeicherbar – Clients sollten in der Lage sein, die Antworten zur weiteren Verwendung zwischenzuspeichern.
Der Unterschied zwischen REST und SOAP ist unten aufgeführt: SOAP REST SOAP steht für Simple Object Access Protocol. REST steht für REpresentational State Transfer. Es handelt sich um ein XML-basiertes Protokoll, das auf HTTP oder manchmal TCP/IP und SMTP aufbaut. REST ist kein Protokoll, sondern eine quellenbasierte Architektur im Architekturstil. SOAP verfügt über Spezifikationen sowohl für die zustandslose als auch für die zustandsbehaftete Implementierung. REST ist völlig zustandslos. SOAP erzwingt das Nachrichtenformat XML. REST erzwingt kein Nachrichtenformat als XML oder JSON. SOAP verfügt über eine definierte Standardspezifikation. Beispielsweise ist WS-Security die Spezifikation für die Implementierung von Sicherheit. Es gibt keine definierten Standardspezifikationen. Die SOAP-Nachricht besteht aus einem Umschlag, der SOAP-Header und -Text enthält, um die eigentlichen Informationen zu speichern, die Sie senden möchten. REST verwendet die integrierten HTTP-Header (mit einer Vielzahl von Medientypen), um Metainformationen zu übertragen, und verwendet die Verben GET, POST, PUT und DELETE, um CRUD-Operationen durchzuführen. SOAP verwendet Schnittstellen und benannte Operationen, um Ihren Dienst verfügbar zu machen. REST verwendet URI und Methoden wie (GET, PUT, POST, DELETE), um Ressourcen verfügbar zu machen. Die Leistung ist im Vergleich zu REST langsam. REST ist im Vergleich zu SOAP schnell.
Die ASP.NET WEB API ist ein Framework zum Erstellen von HTTP-Diensten, die von einer Vielzahl von Clients genutzt werden können, darunter Browser, Mobiltelefone, iPhones und Tablets. Es ist ASP.NET MVC sehr ähnlich, da es die MVC-Funktionen wie Routing, Controller, Aktionsergebnisse, Filter, Modellbinder, IOC-Container oder Abhängigkeitsinjektion enthält. Es ist jedoch nicht Teil des MVC Framework. Es ist Teil der ASP.NET-Kernplattform und kann mit MVC und anderen Arten von Webanwendungen wie ASP.NET WebForms verwendet werden. Es kann auch als eigenständige Webdienstanwendung verwendet werden. Funktionen der ASP.NET WEB API: 1. Sie unterstützt konventionsbasierte CRUD-Aktionen, da sie mit den HTTP-Verben GET, POST, PUT und DELETE funktioniert. 2. Antworten haben einen Accept-Header und einen HTTP-Statuscode. 3. Antworten werden vom MediaTypeFormatter der WEB-API in JSON, XML oder ein beliebiges Format formatiert, das Sie als MediaTypeFormatter hinzufügen möchten. 4. Es akzeptiert und generiert möglicherweise Inhalte, die möglicherweise nicht objektorientiert sind, wie Bilder, PDF-Dateien usw. 5. Es bietet automatische Unterstützung für OData. Durch Platzieren des neuen Attributs [Queryable] in einer Controller-Methode, die IQueryable zurückgibt, können Clients die Methode für die Erstellung von OData-Abfragen verwenden. 6. Es kann in der Anwendung oder auf IIS gehostet werden. 7. Es unterstützt auch die MVC-Funktionen wie Routing, Controller, Aktionsergebnisse, Filter, Modellbinder, IOC-Container oder Abhängigkeitsinjektion, was es einfacher und robuster macht.
Heutzutage reicht eine webbasierte Anwendung nicht aus, um ihre Kunden zu erreichen. Die Menschen sind sehr schlau und nutzen im täglichen Leben iPhones, Mobiltelefone, Tablets usw. Diese Geräte verfügen auch über viele Apps, die Ihnen das Leben erleichtern. Tatsächlich bewegen wir uns vom Web in die Welt der Apps.
Wenn Sie also Ihre Servicedaten schnell und einfach den Browsern und den Apps all dieser modernen Geräte zur Verfügung stellen möchten, sollten Sie über eine API verfügen, die mit Browsern und all diesen Geräten kompatibel ist.
Zum Beispiel Twitter, Facebook und Google API für die Webanwendung und Telefon-Apps.
Die WEB-API ist das großartige Framework, um Ihre Daten und Dienste auf verschiedenen Geräten verfügbar zu machen. Darüber hinaus ist die WEB-API Open Source und eine ideale Plattform zum Erstellen von REST-fähigen Diensten über das .NET Framework. Im Gegensatz zum WCF-Rest-Dienst nutzt er alle Funktionen von HTTP (wie URIs, Anforderungs-/Antwort-Header, Caching, Versionierung, verschiedene Inhaltsformate) und Sie müssen im Gegensatz zum WCF-Rest-Dienst keine zusätzlichen Konfigurationseinstellungen für verschiedene Geräte definieren.
Wenn wir einen Webdienst und kein SOAP benötigen, ist die ASP.NET WEB API die beste Wahl.
Es wird verwendet, um einfache, nicht SOAP-basierte HTTP-Dienste auf der Grundlage der vorhandenen WCF-Nachrichtenpipeline zu erstellen.
Es gibt keine langwierige und umfangreiche Konfiguration wie der WCF-REST-Dienst.
Einfache Serviceerstellung mit WEB-API. Mit WCF REST Services ist die Diensterstellung schwierig.
Es basiert nur auf HTTP und ist einfach auf REST-fähige Weise zu definieren, verfügbar zu machen und zu nutzen.
Es handelt sich um eine leichte Architektur, die sich gut für Geräte mit begrenzter Bandbreite wie Smartphones eignet.
Es ist Open Source.
Das .NET-Framework verfügt über eine Reihe von Technologien, mit denen Sie HTTP-Dienste wie Webservice, WCF und jetzt auch die WEB-API erstellen können. Zwischen diesen vier gibt es folgende Unterschiede:
Webdienst
Es basiert auf SOAP und gibt Daten im XML-Format zurück.
Es unterstützt nur das HTTP-Protokoll.
Es ist kein Open Source, kann aber von jedem Client genutzt werden, der XML versteht.
Es kann nur auf IIS gehostet werden.
WCF
Es basiert ebenfalls auf SOAP und gibt Daten in XML-Form zurück.
Es ist die Weiterentwicklung des Webdienstes (ASMX) und unterstützt verschiedene Protokolle wie TCP, HTTP, HTTPS, Named Pipes, MSMQ.
Das Hauptproblem bei WCF ist die langwierige und umfangreiche Konfiguration.
Es ist kein Open Source, kann aber von jedem Client genutzt werden, der XML versteht.
Es kann in der Anwendung oder auf IIS gehostet werden oder den Windows-Dienst verwenden.
WCF Rest
Um WCF als WCF-Restdienst verwenden zu können, müssen Sie webHttpBindings aktivieren.
Es unterstützt HTTP-GET- und POST-Verben durch die Attribute [WebGet] bzw. [WebInvoke].
Um andere HTTP-Verben zu aktivieren, müssen Sie in IIS einige Konfigurationen vornehmen, um die Anforderung dieses bestimmten Verbs in .svc-Dateien zu akzeptieren
Die Übergabe von Daten über Parameter mithilfe eines WebGet erfordert eine Konfiguration. Das UriTemplate muss angegeben werden
Es unterstützt die Datenformate XML, JSON und ATOM.
WEB-API
Dies ist das neue Framework zum einfachen Erstellen von HTTP-Diensten.
Die WEB-API ist Open Source und eine ideale Plattform zum Erstellen von REST-fähigen Diensten über das .NET Framework.
Im Gegensatz zum WCF-Rest-Dienst nutzt er alle Funktionen von HTTP (wie URIs, Anforderungs-/Antwort-Header, Caching, Versionierung, verschiedene Inhaltsformate).
Es unterstützt auch die MVC-Funktionen wie Routing, Controller, Aktionsergebnisse, Filter, Modellbinder, IOC-Container oder Abhängigkeitsinjektion sowie Unit-Tests, was es einfacher und robuster macht.
Es kann in der Anwendung oder auf IIS gehostet werden.
Es handelt sich um eine leichte Architektur, die sich gut für Geräte mit begrenzter Bandbreite wie Smartphones eignet.
Antworten werden vom MediaTypeFormatter der WEB-API in JSON, XML oder ein beliebiges Format, das Sie als MediaTypeFormatter hinzufügen möchten, formatiert.
Folgende Punkte helfen Ihnen bei der Wahl zwischen WCF und WEB API:
Wählen Sie WCF, wenn Sie einen Dienst erstellen möchten, der spezielle Szenarien wie Einwegnachrichten, Nachrichtenwarteschlangen, Duplexkommunikation usw. unterstützen soll.
Wählen Sie WCF, wenn Sie einen Dienst erstellen möchten, der schnelle Transportkanäle verwenden kann, wenn verfügbar, wie TCP, Named Pipes oder vielleicht sogar UDP (in WCF 4.5), und wenn Sie auch HTTP unterstützen möchten, wenn alle anderen Transportkanäle nicht verfügbar sind.
Wählen Sie die WEB-API, wenn Sie ressourcenorientierte Dienste über HTTP erstellen möchten, die alle Funktionen von HTTP nutzen können (wie URIs, Anforderungs-/Antwort-Header, Caching, Versionierung, verschiedene Inhaltsformate).
Wählen Sie die WEB-API, wenn Sie Ihren Dienst einer breiten Palette von Clients zugänglich machen möchten, darunter Browser, Mobiltelefone, iPhones und Tablets.
Es gibt folgende Unterschiede zwischen ASP.NET MVC und der WEB-API:
ASP.NET MVC wird verwendet, um Webanwendungen zu erstellen, die sowohl Ansichten als auch Daten zurückgeben, aber die ASP.NET WEB-API wird verwendet, um auf einfache Weise vollständige HTTP-Dienste zu erstellen, die nur Daten und keine Ansichten zurückgeben.
Die WEB-API hilft beim Aufbau von REST-fähigen Diensten über das .NET Framework und unterstützt auch die Inhaltsaushandlung (es geht darum, die besten Antwortformatdaten zu bestimmen, die vom Client akzeptiert werden könnten. Dabei kann es sich um JSON, XML, ATOM oder andere formatierte Daten handeln ), Selbsthosting, die nicht in MVC enthalten sind.
Die WEB-API kümmert sich auch um die Rückgabe von Daten in einem bestimmten Format wie JSON, XML oder einem anderen, basierend auf dem Accept-Header in der Anfrage, und Sie müssen sich darüber keine Sorgen machen. MVC gibt mithilfe von JsonResult nur Daten im JSON-Format zurück.
In der WEB-API wird die Anforderung den Aktionen basierend auf HTTP-Verben zugeordnet, in MVC jedoch dem Aktionsnamen.
Die ASP.NET WEB API ist ein neues Framework und Teil des Kern-ASP.NET-Frameworks. Die Modellbindung, Filter, Routing und andere MVC-Funktionen in der WEB-API unterscheiden sich von MVC und sind in der neuen System.Web.Http-Assembly vorhanden. In MVC sind diese Funktionen in System.Web.Mvc vorhanden. Daher kann die WEB-API auch mit ASP.NET und als eigenständige Serviceschicht verwendet werden.
Sie können WEB-API und MVC-Controller in einem einzigen Projekt kombinieren, um erweiterte AJAX-Anfragen zu verarbeiten, die Daten in JSON, XML oder einem anderen Format zurückgeben können, und einen vollständigen HTTP-Dienst zu erstellen. Typischerweise wird dies als WEB-API-Selbsthosting bezeichnet.
Wenn Sie einen gemischten MVC- und WEB-API-Controller haben und die Autorisierung implementieren möchten, müssen Sie zwei Filter erstellen, einen für MVC und einen anderen für die WEB-API, da beide unterschiedlich sind.
Darüber hinaus handelt es sich bei der WEB-API um eine leichte Architektur, die neben der Webanwendung auch mit Smartphone-Apps verwendet werden kann.
Im Gegensatz zu ASP.NET MVC wird die WEB-API nur zur Rückgabe von Daten verwendet. Die Daten können Zeichenfolgen, JSON, XML, Text usw. sein. Es kann keine Ansicht wie bei ASP.NET MVC zurückgegeben werden.
Wie bei ASP.NET MVC können Sie auch den Namen der WEB-API-Aktion ändern, indem Sie das ActionName-Attribut wie unten angegeben verwenden:
[HttpGet] [ActionName("GetProducts")] public IEnumerable ProductList() { return db.Products.AsEnumerable(); }
Wie bei ASP.NET MVC können Sie auch den Aufruf der WEB-API-Aktionsmethode nur durch eine bestimmte HTTP-Anfrage einschränken, indem Sie das Attribut HttpGet, HttpPost, HttpPut oder HttpDelete anwenden.
Wenn Sie eine Aktionsmethode nur für HTTP-Get-Anfragen einschränken möchten, ergänzen Sie sie mit dem HttpGet-Aktionsmethodenauswahlattribut wie unten angegeben:
[HttpGet] public IEnumerable ProductList() { return db.Products.AsEnumerable(); }
Die ASP.NET-WEB-API kann mithilfe von HttpClient und der WEB-API-Adresse wie unten angegeben aufgerufen werden:
öffentliche Klasse ProductController: Controller { HttpClient Client = new HttpClient(); Uri BaseAddress = new Uri("http://localhost:131/"); public ActionResult Index() { Client.BaseAddress = BaseAddress; HttpResponseMessage Response = Client.GetAsync("productservice/GetProducts").Result; if (response.IsSuccessStatusCode) { var data = Response.Content.ReadAsAsync<IEnumerable>().Result; return View(data); } return View(); } }
ASP.NET MVC und ASP.NET WEB API verwenden beide Routing, um eingehende Anforderungen zu überwachen, und es ist mindestens eine Route definiert, um zu funktionieren. Der Unterschied zwischen diesen beiden Routen ist unten angegeben:
Im WEB-API-Routenmuster ist der Parameter {action} optional, Sie können jedoch einen Parameter {action} einfügen. In ASP.NET MVC ist der Parameter {action} obligatorisch.
Die im API-Controller definierten Aktionsmethoden müssen entweder das Attribut HTTP-Aktionsverben (GET, POST, PUT, DELETE) oder eines der HTTP-Aktionsverben als Präfix für den Namen der Aktionsmethoden haben. In ASP.NET MVC kann eine Aktionsmethode standardmäßig durch HTTP-GET- oder POST-Verben aufgerufen werden. Für die Verwendung anderer HTTP-Verben müssen Sie diese als Attribut definieren.
Im Gegensatz zu ASP.NET MVC kann die Web-API nur einen komplexen Typ als Parameter empfangen.
Das Aktivieren des Attributroutings in Ihrer ASP.NET WEB API2 ist einfach. Fügen Sie einfach einen Aufruf der Methode MapHttpAttributeRoutes() in der Methode Register() der Datei WebApiConfig.cs hinzu.
öffentliche statische Klasse WebApiConfig { public static void Register(HttpConfiguration config) { //Attributrouting aktivieren config.MapHttpAttributeRoutes(); } }
Sie können Attributrouting auch mit konventionsbasiertem Routing kombinieren.
öffentliche statische Klasse WebApiConfig { public static void Register(HttpConfiguration config) {
//Attributrouting aktivieren config.MapHttpAttributeRoutes(); // Konventionsbasiertes Routing. config.Routes.MapHttpRoute( Name: „DefaultApi“,
routeTemplate: "api/{controller}/{id}", Standardwerte: new { id = RouteParameter.Optional });
} }
Wie bei ASP.NET MVC5 können Sie auch in WEB API2 das Attributrouting auf Controller- und Aktionsebene definieren, wie unten gezeigt:
[RoutePrefix("Service/User")] public class UserController : ApiController { //GET route: api/User public IEnumerable Get() { return new string[] { "value1", "value2" };
}
[Route("{id}")] //GET route: Service/User/1 public string Get(int id) { return "value"; }
[Route("")] //POST-Route: Service/User/ public void Post([FromBody]string value) { } }
• Routing auf Aktionsebene – Sie können Routen auf Aktionsebene definieren, die für eine bestimmte Aktion im Controller gelten.
öffentliche Klasse UserController: ApiController { //GET Route: api/User
public IEnumerable Get() { return new string[] { "value1", "value2" };
}
[Route("Service/User/{id}")] //GET route: Service/User/1 public string Get(int id) { return "value"; } [Route("Service/User/")] //POST-Route: Service/User/ public void Post([FromBody]string value) { } }
