Ein grundlegendes Verständnis des HTTP-Protokolls ist die Grundlage für das Verständnis und die Verwendung der RestFul-Stil-API. Nachdem Sie diese Grundlagen verstanden haben, verwenden Sie verschiedene RestFul-Entwicklungs-Frameworks Sie können praktisch sein. Als ich anfing, WebApi zu verwenden, fühlte ich mich aufgrund meines mangelnden Verständnisses dieser Kenntnisse nicht wohl. Erst als ich mich mit diesen HTTP-Kenntnissen vertraut machte, fühlte ich mich bei der Entwicklung wohl. Die API im RestFul-Stil ist eine API, die das HTTP-Protokoll gut unterstützt und den vollständigen semantischen Stil von HTTP implementiert.
Bevor ich dieses Wissen vorstelle, muss ich ein Missverständnis betonen, das viele Menschen haben: HTTP-Prädikate und Datenübertragungsmethoden. Das HTTP-Protokoll, mit dem die meisten Menschen in Kontakt kommen und das sie beim Schreiben von Websites verwenden, verwenden wir nur die beiden Prädikate GET und POST, und andere Prädikate sind bei vielen Menschen nicht anwendbar Seltsame Erkenntnisse: Das HTTP-Protokoll ist nur für die Website-Entwicklung geeignet: Die Datenübertragung über HTTP-Aufrufe erfolgt nur in Form von K-V. Die Entwicklung erfolgt in diesem Stil Die Verwendung von ASP.NET WebAPi erscheint ebenfalls unscheinbar, was zu Problemen führt. Wir müssen uns zunächst darüber im Klaren sein, dass die Dateninteraktion auf der Website nur ein Szenario der HTTP-Nutzung ist und HTTP verschiedene Formen von Daten übertragen kann.
Wir beginnen mit der ersten Zeile von HTTP: Die erste Zeile von HTTP enthält drei Informationen: Prädikat, URL und HTTP-Protokollversion. Die drei Daten werden durch Leerzeichen getrennt.
Prädikat: Prädikat ist ein sehr wichtiges Element für die RestFul-API und verwendet Prädikate als Standard-Routing-Methode. Die am häufigsten verwendeten Prädikate sind: POSTDELETEPUTGET Diese vier Prädikate entsprechen den vier Aktionen „Hinzufügen, Löschen, Ändern und Überprüfen“ (POST und PUT werden zum Hinzufügen und Ändern verschiedener Daten verwendet. Es gibt immer unterschiedliche Meinungen. Ich bin tatsächlich etwas verwirrt ... Ja Die Definition besagt, dass PUT eine idempotente Operation ist, POST jedoch nicht, sodass PUT mehr auf Änderungen und POST auf Erhöhungen ausgerichtet ist. Die am häufigsten verwendeten Prädikate sind diese vier, und es gibt weitere Prädikate mit unterschiedlicher Semantik:
HEAD: gibt nur den entsprechenden Header zurück, ausgenommen Body
TRACE: Ja Diagnose der Datenübertragungsprozess
OPTIONEN: Fordern Sie den Webserver auf, die verschiedenen von ihm unterstützten Funktionen zu informieren
Bei Bedarf können Sie verwandte Dokumente abfragen nicht häufig verwendet.
Unter diesen enthalten GET und DELETE keinen BODY, während PUT und POST BODY enthalten können. Und wenn ein Prädikat Operationen außerhalb der Semantik enthält, wie z. B. GET mit BODY, wird POST zum Löschen von Ressourcen verwendet. Diese Operation ist ebenfalls zulässig und wird als Überladung des Prädikats bezeichnet. Obwohl HTTP das Überladen von Prädikaten unterstützen kann, wird seine Verwendung nicht empfohlen, da es nicht der Standardsemantik entspricht.
URL: URL definiert eine Ressource, z. B. www.example.com/person definiert Person als Ressource, wir stellen Person bereit Reihe von Operationen:
GET www.example/person/1, um die Informationen des Benutzers mit ID 1 zu erhalten
POST www.example/person/ (in BODY Enthält die Beschreibung einer Person) Erstellen Sie eine Personenressource
PUT www.example/person/1 (BODY enthält die Beschreibung einer Person) AktualisierenEine Personenressource
.1-Protokoll, das HTTP2.0-Protokoll befindet sich in der Popularisierungsphase und wird noch nicht häufig verwendet. Der Unterschied zwischen HTTP1.0 und HTTP1.1 ist sehr gering und hat keine großen Auswirkungen auf RestFul. Für konkrete Unterschiede können Sie die entsprechenden Dokumente prüfen.
Dies ist die erste Zeile von HTTP. Als nächstes folgt ein RN, um die Zeile zu unterbrechen. Als nächstes folgt der HTTP-HEAD-Teil, der die HTTP-Anfrage und -Antwort beschreibt. Ich denke, HTTP HEAD ist der wichtigste Teil des HTTP-Protokolls. Es enthält Informationen wie Codierung, BODY-Länge, Inhaltsaushandlung usw. Sie können auch einige benutzerdefinierte Informationen hinzufügen. Lassen Sie mich Ihnen einige HEADs vorstellen, die häufig in der RestFul-API verwendet werden:
User-Agent: Benutzeragent, welcher Client die Anfrage stellt, z. B. IE, Chrome, Fid dl ähm usw.
HOST: Domänenname (HOST wird im Allgemeinen für die Site-Bindung des Servers verwendet. Er ist im Allgemeinen derselbe wie der Domänenname der URL, wird jedoch in einigen benutzerdefinierten DNS-Verwendungen verwendet kann erscheinen. Die Domänennamen in HOST und URL sind inkonsistent)
Autorisierung: Verifizierungsinformationen, dieses Feld kann einige Informationen zur Benutzerverifizierung enthalten, und die Darstellungsmethode ist: Schema-Autoreninfo, durch Leerzeichen getrennt, wobei Schema die Verifizierung darstellt Die Methode „authorinfo“ stellt Verifizierungsinformationen dar, ein gängiges Schema wie „Base“: „authorinfo“ verwendet Benutzernamen + Passwort und ist mit Base64 codiert. Oder verwenden Sie Token, ähnlich wie Session.
Akzeptieren: Welche Serialisierungsmethode zum Akzeptieren der zurückgegebenen Daten, ausgedrückt in MIME, zur Inhaltsaushandlung von Antwortdaten verwendet wird, kann mehrere MIME enthalten, geordnet nach Priorität, z. B. application/json, application/xml, text/html; der spezifische Datentyp, den der Server zurückgeben kann, hängt von der Serverunterstützung ab. Manchmal benötigen wir auch einige benutzerdefinierte MIME. Wie BSON, Protokollpuffer usw. können wir MIME anpassen und unsere eigene Implementierung auf der Serverseite entwickeln. Diese speziellen Erweiterungen verfügen über entsprechende Erweiterungspunkte in ASP.NET WebApi.
Content-Type: Verwenden Sie eine MIME-Darstellung, um die Serialisierungsmethode des Hauptteils der gesendeten Anfrage anzugeben. Übliche Methoden sind application/json und application/x-www-, die am häufigsten verwendet werden für WEB-Interaktion. Fürm-urlencoded stellen beide die Serialisierungsmethode Ihres Körperteils dar, die in der Anfrage und Antwort angezeigt wird.
Ich denke, der HTTP-HEAD-Teil ist Der Kern des HTTP-Protokolls ist so groß, dass es viele Details gibt, die in meiner Arbeit am häufigsten verwendet werden. Alle Informationen zur Einführung dieser Inhalte reichen aus Der gesamte Prozess ist jetzt verfügbar. Wenn Sie interessiert sind, finden Sie in der Rest-API häufig Verwirrung über die Funktionen und Unterschiede zwischen den Inhalten Die beiden Header „Accept“ und „Content-Type“ geben an, welche Art von Daten akzeptiert werden. Content-Type gibt die Codierungsmethode des Körpers in der aktuellen Anfrage an. Wenn in ASP.NET WEBAPI ein Content-Type in der Anfrage, aber kein ACCEPT vorhanden ist, wird der Inhalt im Content-Type standardmäßig als Inhaltsaushandlung für die Antwort verwendet.
Der Antwortteil ist ebenfalls in Header und Body unterteilt. Der größte Unterschied zwischen dem Antwortheader und dem Anforderungsheader besteht darin, dass sich in der ersten Zeile der Antwort ein HTTP-Code befindet Der HTTP-Code wird als API-Aufruf verwendet Die Statusanzeige ist ebenfalls sehr wichtig. Der am häufigsten verwendete Statuscode in der REST-API besteht im Allgemeinen aus drei Segmenten: 2XX, 4XX und 5XX 1XX bedeutet, dass die Arbeit fortgesetzt wird, und 3XX bedeutet im Allgemeinen eine Umleitung, die in REST-APIs nicht häufig verwendet wird. Unter den drei am häufigsten verwendeten Statussegmenten zeigt 2XX eine erfolgreiche Ausführung an, 4XX zeigt Clientdatenfehler an (z. B. Parameterüberprüfungsfehler) und 5XX zeigt serverseitige Verarbeitungsfehler an, z. B. nicht behandelte Ausnahmen (z. B. Datenbankverbindungsfehler). Anhand dieser Statuscodes kann zunächst der Ausführungsstatus des API-Aufrufs beurteilt werden.
Nach dem Header befindet sich eine Leerzeile (rn), gefolgt von „Content“. Hier finden Sie spezifische Geschäftsdaten, die durch unterschiedliche Serialisierungsmethoden entsprechend unterschiedlicher Inhaltstypen wie JSON, XML und sogar HTML dargestellt werden. Wenn Sie die HTTP-API lernen, können Sie denken, dass Webanwendungen auch eine Anwendung von HTTP sind, aber die Interaktionsmethode verwendet im Allgemeinen application/x-www-form-urlencoded als Anforderung und text/html als Antwort. RestAPI kann mit vielen anderen Codierungsmethoden interagieren und unterstützt eine breitere Palette von Anwendungen. Webanwendungen sind nur ein Anwendungsszenario, das die HTTP-Übertragung verwendet und Webseiten nicht trennen kann. Ich denke, dass Nancy dies besser macht als ASP.NET. Nancy trennt RestAPI nicht von der Webseite, während ASP.NET die beiden mithilfe von MVC und WEBAPI trennt JSON-Daten zurückgeben, wenn es sich um application/json handelt, und eine Webseite zurückgeben, wenn text/html verwendet wird. Das Ausschneiden oder Zusammenführen dieser beiden Anwendungsmethoden hat natürlich seine eigenen Vor- und Nachteile.
Was ich geschrieben habe, ist zu wenig für das HTTP-Protokoll. Wenn Sie interessiert sind, können Sie selbst nach relevanten Informationen suchen. Ich habe gerade die häufig verwendeten Teile der WEB-API aufgeschrieben Das Bild zeigt Ihnen dieses Wissen:
Das obige ist der detaillierte Inhalt vonASP.NET WebAPI-Vorkenntnisse: HTTP und RestfulAPI. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
