Lassen Sie mich damit beginnen, Ihnen
eine kurze 10-minütige Einführung in das Essentials of Networking zu geben.
Angesichts der Tatsache, dass wir begrenzte Zeit haben,
würde ich mich darauf konzentrieren, Ihnen
das Wesentliche zu liefern, das Sie benötigen, um jedes der Themen zu verstehen.
Was wir nun in diesem speziellen Modul abdecken, erfordert
zumindest ein rudimentäres Verständnis dafür, wie
Computernetzwerk funktioniert, bevor wir verstehen, warum wir HTTP verwenden müssen,
warum wir mit einem Server kommunizieren,
was ist der Grund für die Verzögerung, wenn Sie mit einem Server sprechen und so weiter.
Und auch die verschiedenen Protokolle, die Sie
beachten müssen, bevor Sie sogar mit einem Server kommunizieren können.
Also, all dies im Hinterkopf,
eine 10-minütige kurze Einführung in das Essentials of Networking.
Wir beginnen zu erkennen, dass Webanwendungen nicht mehr eigenständig sind.
Sie haben immer ein Angebot unquote Cloud-Backend unterstützt Ihre Web-Anwendung.
Heutzutage ist alles in der Cloud.
Ziemlich bald wirst du auch auf der Cloud sein,
zumindest auf Wolke neun mit silbernem Futter.
Aber angesichts der Tatsache, dass wir
eine serverseitige Unterstützung benötigen, damit unsere Winkelanwendung korrekt funktioniert,
würden Sie den Server hosten.
Und heutzutage ist das Hosten des Servers sehr
einfach, indem Sie einen der Cloud-basierten Infrastrukturdienste verwenden,
Dinge wie Amazon Web Services oder Heroku oder Digital
Ocean oder viele andere, die cloudbasierte Serverunterstützung bieten.
Also, was genau ist auf der Serverseite verfügbar?
Sie haben normalerweise ein Server-Frontend, das mit Ihrer Winkelanwendung spricht,
also die Serverlogik und hinter den Kulissen kommuniziert die Serverlogik mit
einem persistenten Speicher wie einer Datenbank, in der Ihre Daten gespeichert und abgerufen werden.
Wenn Sie die Netzwerkwelt betreten,
werden Sie ziemlich bald mit 304 kleinen Akronymen bombardiert werden,
Dinge, von denen Sie dachten, dass Sie wussten, was sie aus normalem Englisch stammen, oder sie haben
eine ganz andere Bedeutung oder
Zweck, wenn Sie ihnen in dieser Netzwerkwelt begegnen.
Also lassen Sie uns ein paar von ihnen untersuchen.
Also in der Netzwerkwelt werden Sie Leute hören, die über HTTP-Protokoll sprechen.
Das Protokoll, das für die Kommunikation zwischen dem Client und dem Server verwendet wird.
Dies ist ein Anwendungs-Layer-Protokoll,
über das wir kurz im Rest dieser Vorlesung sprechen werden.
Das HTTP-Protokoll, damit es funktioniert, benötigt eine URL, den
Uniform Resource Locator, zur Verfügung gestellt werden.
Dies ist also eine Zeichenfolge, die durch Schrägstriche getrennt ist,
mit einem HTTP-Doppelpunkt oder einem HTTPS-Doppelpunkt davor.
Und ich bin mir sicher, wenn Sie das World Wide Web verwendet haben,
sind Sie ziemlich vertraut mit dem, wie die URLs aussehen.
Außerdem würden Sie hören, wie Leute über JSON sprechen,
nicht Ihren Freund Jason, sondern JavaScript Object Notation.
Die JavaScript-Objekt-Notation ist also eine Möglichkeit, Daten
zu codieren, die von der Serverseite zur Clientseite oder umgekehrt geliefert werden.
Und Sie werden auch hören, wie Leute über XML sprechen noch eine andere Möglichkeit,
Daten zu codieren, während es in Transitversand zwischen der Client- und Serverseite ist.
Nun werden Sie auch hören, wie Leute über höherwertige Protokolle namens SOAP sprechen,
nicht die Art, mit der Sie eine Dusche nehmen, sondern SOAP als ein Protokoll, das die
Kommunikation zwischen Verteilungseinheiten innerhalb ihres Netzwerks ermöglicht.
Und Sie werden auch hören, wie Leute über REST sprechen,
nicht etwas, das Sie zu viel durch diesen speziellen Kurs bekommen,
REST oder Representational State Transfer.
Ich werde einen kürzeren Vortrag, der
speziell REST gewidmet ist, ein wenig später in diesem Modul haben.
Und in der HTTP-Welt
würden Sie Leute hören, die über GET, PUT
, POST und DELETE sprechen und Sie würden sich fragen,
was sie alle bedeuten?
Lassen Sie uns ein wenig darüber in
dieser Vorlesung lernen und auch den Vortrag über REST, den Sie ein wenig später sehen werden.
Eine wichtige Sache, die Sie verstehen müssen, wenn Sie
mit einem Server kommunizieren, ist, dass die Client-Server-Kommunikation
unerwartete Verzögerungen oder unbestimmte Verzögerungen verursacht,
während die Daten entweder abgerufen oder vom Clientstandort auf den Server hochgeladen werden.
Das bedeutet, dass
Sie innerhalb Ihrer Client-Site-Anwendung den Benutzer über die Tatsache informieren müssen, dass
etwas hinter den Kulissen passiert und in der
Lage sein, die Verzögerungen zu behandeln und
möglicherweise nicht in der Lage sein, die Daten von der Serverseite zu erhalten.
Es ist durchaus möglich, dass, wenn Sie versuchen, eine Verbindung mit einem Server herzustellen,
die Verbindung des Servers fehlschlägt,
der Server möglicherweise falsche Daten zurückgibt oder einen Kommunikationsfehler verursachen kann.
All diese müssen auf Ihrer Clientseite entsprechend behandelt werden, damit Ihre Anwendung
auch bei Vorliegen dieser Probleme weiterhin funktioniert.
Springen Sie in das gängigste Protokoll der Anwendungsschicht, das
für die Kommunikation zwischen dem Client und dem Server verwendet wird,
das Hypertext Transfer Protocol.
Aber das ist ein Client-Server-Kommunikationsprotokoll.
Nun kann oder auch nicht viel Sinn für Sie machen,
es sei denn, Sie haben einen ausreichenden Hintergrund im Netzwerk,
aber dies ist ein Protokoll, das für die Kodierung der Nachrichten verwendet wird, die Sie
zwischen Ihrer Client-Anwendung ausgetauscht haben, die
in diesem Fall eine eckige Anwendung ist, und einer Serverseite.
Dieses HTTP-Protokoll ermöglicht es Ihnen,
hypertext-basierte Dokumente von der Serverseite abzurufen,
zunehmend werden die Informationen, die von der Serverseite heruntergeladen werden,
in einem der Standard-Codierungsformate wie JSON oder XML codiert.
Und um mit einem Server sprechen zu können,
haben Sie die Unterstützung von verschiedenen HTTP-Aktionen oder was wir als HTTP-Verben bezeichnen,
die HEAD, GET, POST,
PUT, DELETE, TRACE, OPTIONS und CONNECT.
Wir werden insbesondere die
Verben GET, PUT, POST und DELETE genauer sehen, wenn wir das REST-API-Protokoll ein wenig später untersuchen.
Wie funktioniert das HTTP-Protokoll?
Im HTTP-Protokoll
senden Sie GET-Anforderung von Ihrer Clientanwendung an den Server.
Und dies ist in Form einer HTTP-Anforderungsnachricht codiert.
Die Anforderungsnachricht enthält in
der Regel eine URL in der Anforderungsnachricht, die angibt, was die Serverseite Ihnen senden soll.
Und dies ist in der Regel eine GET-Nachricht, wenn Sie möchten
, dass Daten von der Serverseite heruntergeladen werden.
Sie geben auch an, mit welchem bestimmten Server Sie kommunizieren.
Wenn der Server Ihre Anfrage erhält,
ruft der Server die Daten aus seinem Datenspeicher ab, in der
Regel eine Datenbank auf der Serverseite,
und packt diese Daten dann in
einem geeigneten Format und sendet die Daten an Sie auf Ihrer Clientseite zurück.
Wenn Sie Standard-HTML-, CSS-
und JavaScript-Code von der Serverseite erhalten,
ist Ihr Browser in der Lage, dies zu rendern.
Bei Anwendungen wie Angular
stellen Sie jedoch in erster Linie eine Verbindung zum Server her und
rufen dann die meiste Zeit Daten in Form von JSON oder XML ab.
Mit Ausnahme des ersten Downloads aller Ressourcen, die
für die Ausführung Ihrer Angular-Anwendung in Ihrem Browser erforderlich sind.
Wie wir bereits gesehen haben,
erfordert die HTTP-Anwendung, dass Nachrichten zwischen dem Client und dem Server gesendet werden.
Eine Anforderungsnachricht wird normalerweise vom Client an den Server gesendet, und
die Anforderungsnachricht besteht aus einer Anforderungszeile plus einer Reihe von Headern,
in denen Sie zusätzliche Informationen zur Qualifizierung der Anforderung angeben.
Wir werden die Verwendung verschiedener Header und Einstellungen in
den Kopfzeilen sehen, während wir einige der Übungen in diesem speziellen Modul durchlaufen.
Die Anforderungszeile und die Kopfzeilen werden durch
eine leere Zeile vom Text der Anforderungsnachricht getrennt.
Der Nachrichtentext kann zusätzliche Daten enthalten,
insbesondere wenn Ihr Client Daten an die Serverseite sendet.
Wenn Sie beispielsweise ein Formular senden, werden
die Informationen innerhalb des Formulars in
ein JSON-Format codiert und dann von der Clientseite an die Serverseite gesendet.
Das wird also entweder mit einem POST- oder einer PUT-Nachricht geschehen.
Betrachtet man die wenig mehr Details der HTTP-Anforderungsnachricht,
enthält die typische Anforderungsnachricht in der Anforderungszeile die Methode, die entweder GET, PUT, POST,
DELETE oder einige der anderen Verben, die Sie zuvor gesehen haben,
und dann gefolgt von der URL und der Version
des HTTP-Protokoll, das Sie für die Kommunikation vom Client zur Serverseite verwenden.
Das Kopfzeilenfeld enthält normalerweise einen Kopfzeilenfeldnamen, einen
Doppelpunkt und den Wert für dieses Kopfzeilenfeld.
Und der Körperinhalt
könnte, wie ich bereits erwähnt habe, entweder im JSON- oder XML-Format codiert werden.
Hier ist ein Beispiel für
eine typische HTTP-Anforderungsnachricht, die vom Client an den Server gesendet werden kann.
In dieser speziellen Anforderungsnachricht
bitten wir den Server, die Seite index.html von
der Serverseite zur Clientseite beizubehalten, damit sie
im Browser auf der Clientseite gerendert werden kann.
Eine Anfrage wie diese würde normalerweise einen leeren Körper in der Anforderungsnachricht haben.
Die meisten Informationen werden in der
Anforderungszeile und den Headern der Anforderungsnachricht codiert.
Wenn der Client die Anforderung an den Server sendet.
Der Server verarbeitet die Anfrage und sendet dann eine Antwort an die Client-Seite zurück.
Die Antwortnachricht ist wieder in drei Teilen organisiert,
eine Statuszeile, in der einige Informationen darüber, wie
die Anforderung verarbeitet wurde und was an den Client zurückgesendet wird, gespeichert
wird, die Header zusätzliche Details darüber enthalten, was
in der Antwortnachricht enthalten ist und dann gefolgt von einer leeren Zeile
und dann dem eigentlichen Nachrichtentext.
Ein Beispiel dafür, was normalerweise in einer HTTP-Antwortnachricht enthalten wäre.
In diesem Fall kommt diese Antwortnachricht mit einem 200 zurück
, einem Statuscode der Nachricht.
Wenn in der Anforderungszeile ein 200 als Statuscode angezeigt
wird, bedeutet dies, dass Ihre Anfrage erfolgreich war und der Server die
Daten zurückgeben kann, die Sie von der Serverseite angefordert haben.
Und dann enthält der Header zusätzliche Anweisungen zur
Clientseite, einschließlich Informationen darüber,
wie der eigentliche Nachrichtentext codiert ist.
Dann kann der Text enthalten,
wenn Sie die Seite index.html angefordert haben,
wird der Text der Nachricht den HTML-Code für
die Seite index.html enthalten, wie Sie in diesem Beispiel sehen.
Eine der Informationen in der Statuszeile, die ich als Statuscode bezeichne.
Wenn der Server in der Lage ist, Ihre Anfrage korrekt zu verarbeiten,
sendet er eine Antwort mit dem Statuscode 200 zurück,
was bedeutet, dass alles auf der Serverseite in Ordnung
ist und die Serverseite die Daten korrekt zurückgibt.
Wenn der Server die Anforderung aus irgendeinem Grund nicht verarbeiten kann,
werden diese Informationen im
Statuscode in der Statuszeile der Antwortnachricht codiert.
Die verschiedenen Statuscodes, die normalerweise auftreten, wenn Sie
eine Antwort von der Serverseite erhalten, umfassen eine 201,
was bedeutet, dass, wenn Sie versuchen,
ein Objekt auf der Serverseite zu erstellen, es erfolgreich erstellt wurde,
oder eine 301, was bedeutet, dass alles, was Sie anfordern, verschoben wurde dauerhaft
an einen neuen Speicherort und die URL
des neuen Standorts dieser Ressource wird an Ihre Client-Seite zurückgegeben.
400s und 500s weisen in der Regel darauf hin, dass auf der Serverseite ein Problem vorliegt.
404 ist etwas, das Sie oft begegnen, wenn
Sie nach etwas anfordern, das auf der Serverseite nicht existiert.
Ebenso bedeutet 500, dass der Server nur aufgibt,
Ihre Anfrage nicht verarbeiten kann und dann einen internen Serverfehler zurücksendet.
Dies sind zwei häufige Fehlercodes, die auftreten werden.
Die übrigen haben eine spezifische Bedeutung, wie hier in dieser Tabelle aufgeführt.
Es gibt mehr als die Statuscodes, die ich Ihnen in dieser Tabelle gegeben habe,
aber dies sind einige der häufigsten Statuscodes, die Sie
in einer Antwortnachricht von der Serverseite begegnen werden.
Ein weiterer Punkt, den ich erwähnte, ist die Tatsache, dass der Server
die Daten in einem bestimmten Format wie XML oder Extended Markup Language oder JSON,
dem JavaScript-Object Notation-Format, codieren kann.
In diesem speziellen Kurs
werden wir uns nun normalerweise mit Daten beschäftigen, die hauptsächlich in JSON codiert sind.
Die meisten clientseitigen Anwendungen,
einschließlich mobiler Anwendungen, kommunizieren heutzutage normalerweise mit
dem Server, und das Datenaustauschformat ist in den meisten Fällen standardmäßig JSON.
Das ist der Grund, warum ich ein paar Minuten damit verbringen werde, Ihnen über JSON zu erklären.
Die JavaScript-Objekt-Notation oder JSON ist ein leichtgewichtiges Datenaustauschformat.
Der Grund, warum das JSON-Datenformat für
uns in diesem Kurs besonders interessant ist, liegt darin, dass die JavaScript-Objekt-Notation,
wie der Name schon sagt,
sehr einfach in ein JavaScript-Objekt abgebildet wird, das Sie mit jedem JavaScript-Code verwenden.
Das Konvertieren eines JavaScript-Objekts
in JSON-Notation und umgekehrt ist sehr einfach.
Die JSON-Notation ist das, was wir als
selbstbeschreibende und sehr leicht verständliche Notation nennen.
Im JavaScript Object Notation Format sind
die Daten in einer sehr sauberen, spezifizierten Art und Weise strukturiert.
Dies ist als eine Sammlung von Namen, Wertepaaren
strukturiert, und dies ist als eine geordnete Liste von Werten strukturiert.
Hier sehen Sie ein Beispiel dafür auf der rechten Seite.
Wir haben diese JSON-Daten bereits früher in unserer eckigen Anwendung verwendet.
Also, jetzt sehen Sie, warum die Daten so strukturiert sind.
Und Sie erkennen auch, dass es sehr einfach ist, mit
diesen Daten in Ihrem JavaScript oder Ihrem TypeScript-Code in Ihrer Angular-Anwendung umzugehen.
Damit vervollständige ich einen schnellen Überblick über Netzwerk-Essentials.