Nachdem wir nun die Implementierung
des REST-API-Servers mit Express und MongoDB in diesem Kurs abgeschlossen haben,
ist der nächste sofortige Gedanke, der in Ihrem Kopf auftreten könnte,
da wir bereits die Client-Anwendungen in den vorherigen Kursen entwickelt haben,
wie integrieren wir die beiden zusammen, damit unsere -Clientanwendung in der Lage ist,
mit dem vollwertigen REST-API-Server zu interagieren, den wir in diesem Kurs entwickelt haben? Das
werden wir also in
diesem Vortrag und den beiden Übungen, die dieser Vorlesung folgen, untersuchen.
Am Ende dieser Lektion
haben Sie also React Client, der in der
Lage ist, mit dem Server zu kommunizieren, den Sie gerade in
diesem Kurs entwickelt haben, und in der Lage sein wird,
die vollwertige Client-Seite unserer gesamten Anwendung zu unterstützen.
Auf diese Weise werden wir sehen, dass wir in
diesem Kurs die komplette End-to-End-Anwendung von der Client-Seite bis zur Serverseite entwickelt haben.
Um den Client und den Server zu integrieren,
wie wir festgestellt haben, dass unser Server bereits
implementiert ist, um die vollwertige REST-API zu unterstützen.
Von unserer Client-Seite,
unabhängig davon, ob es sich um den Winkel-Client,
den ionischen Client oder den nativen Skriptclient handelt,
interagieren sie alle mit dem Server über die REST-API-Endpunkte.
Wenn der Client die Anforderung an den Server am REST-API-Endpunkt sendet,
antwortet der Server mit den entsprechenden JSON-Daten zurück an den Client.
Der Client kann dann die JSON-Daten verwenden, um die Ansichten für den Benutzer zu rendern.
Angesichts dieses Verständnisses der Kommunikation zwischen dem Client und dem Server
sollte die Integration ziemlich einfach sein. Nachdem
wir nun die Benutzerauthentifizierung auf unserer Serverseite integriert haben,
müssen wir unsere Client-Anwendungen nachrüsten,
damit sie die Benutzerauthentifizierung auf der Serverseite durchführen können,
indem sie die Anmeldeinformationen auf dem Server veröffentlichen und dann das
Authentifizierungstoken von
der Serverseite erhalten. und danach die Kommunikation mit dem Server
einschließlich des Authentifizierungstoken in der Kopfzeile der Anforderungsnachrichten.
All dies bedeutet also, dass wir kleinere Anpassungen sowohl
am Client als auch am Server vornehmen müssen, damit die beiden miteinander kommunizieren können.
Ein Aspekt, den ich in der Übung zuvor nicht behandelt habe,
ist, wie der Server die Abfrageparameter handhabt, die von der Clientseite stammen.
Also, wie wir erkannten,
wenn die Client-Seite sendet eine Anfrage für
ein vorgestelltes Gericht oder einen vorgestellten Führer oder eine vorgestellte Förderung,
sahen wir, dass die URL enthält,
Gerichte Fragezeichen Funktion ist gleich
wahr in der Anfrage URL, die von der Client-Seite kommt.
Jetzt
haben wir in den Daten auf der Serverseite bereits gesehen, dass das Gericht, die
Promotion oder der Führer das vorgestellte Flag bereits in den JSON-Daten enthält.
Wenn diese Anforderung auf die Serverseite kommt,
sollte der Server in der Lage sein,
diesen Abfrageparameter aus der eingehenden Anfrage zu extrahieren und dann
die Abfrage der
MongoDB entsprechend durchzuführen und dann nur die Ergebnisse zu erhalten, bei denen dieses Feature-Flag auf true gesetzt ist.
Also, um das zu tun, wie wir gesehen haben,
ist die URL, die für das Senden der Anfrage an den Server verwendet wird,
Schrägstrich Gerichte Fragezeichen gekennzeichnet ist gleich wahr.
Also, so werden wir die Abfrageparameter auf unserer Serverseite liefern.
Nun, wenn diese Informationen auf der Serverseite empfangen werden,
haben wir jetzt gesehen, dass früher, als wir die Get Anfrage auf der Serverseite gemacht
haben, wir einfach gesagt, Gerichte finden und dann würden wir
alle Gerichte finden und sie dann zurückgeben, wenn
die get Anfrage an die Schüssel Router Route Schrägstrich gesendet .
Die gleiche Logik gilt sowohl für den Promo-Router als auch für den Leader Router.
Wenn Sie nun einen Abfrageparameter wie diesen in die URL einfügen,
wie wird unsere Serverseite in der Lage sein, diesen Abfrageparameter zu extrahieren?
Wenn die eingehende Anforderung diesen Abfrageparameter an die eingehende URL angehängt hat,
verarbeitet der Express-Server diesen automatisch und wandelt ihn in
ein JSON-Objekt um, das in eine Anforderungsnachricht geladen wird, die auf der Serverseite eingeht.
Nun ist dies serverseitig in Form von req.query verfügbar.
Also, alle Abfrageparameter, die Sie in die URL einfügen, werden in
entsprechende JSON-Objekte mit den Informationen umgewandelt, die
hier festgelegt sind und dann auf das Anforderungsobjekt auf der Serverseite geladen werden.
Also, durch die Verwendung von req.query auf der Serverseite,
werden wir in der Lage sein, diese Abfrageparameter zu erhalten.
Also, wenn Sie eine get-Anfrage auf der Serverseite ausführen, sagen Sie
dishes.find und dann fügen Sie die req.query in die Suche dort ein.
Wenn also die MongoDB
abgefragt wird,
werden nur die Datensätze oder nur die Dokumente, für die das Featured auf true gesetzt ist, aus der MongoDB extrahiert und
uns innerhalb dieser get-Methode hier zurückgegeben und können dann an die Client-Seite zurückgegeben werden.
Dies ist also so einfach wie bei der Verarbeitung der Abfrageparameter auf unserer Serverseite.
Also, dieses Update werden wir sowohl mit dem Dish Router,
dem Promo-Router als auch dem Leader Router auf unserer Serverseite tun.
Der nächste Teil ist
natürlich die Benutzerauthentifizierung.
Also, wie wir festgestellt haben,
haben wir auf der Serverseite bereits
diese REST-API-Endpunkte, die für die Benutzerauthentifizierung nützlich sind,
insbesondere wenn Sie einen Beitrag machen, um Benutzer
mit dem Benutzernamen und Passwort zu schrägen,
dann werden Sie in der Lage sein, den Benutzer auf dem Server zu authentifizieren Seite.
Wenn der Benutzer nun auf der Serverseite erfolgreich authentifiziert wurde,
enthält die Antwortnachricht, die von der Serverseite kommt,
das JSON-Web-Token in den Antworttext der eingehenden Antwortnachricht von der Serverseite.
Also, auf der Client-Seite
sollten wir in der Lage sein, dieses Token zu extrahieren und dann dieses Token später zu verwenden.
Wenn also der Client die Antwortnachricht von
der Serverseite empfängt und der Benutzer erfolgreich auf der Serverseite authentifiziert wurde,
enthält die Antwortnachricht das JSON-Web-Token,
das extrahiert werden muss,
und danach sollte der Client dieses JSON-Web-Token in
die Autorisierungs-Header für jede ausgehende Anforderung von der Client-Seite.
Dies wird erreicht, indem das JSON-Web-Token im lokalen Speicher gespeichert wird.
Danach
können wir für jede Abrufanforderung, die wir ausgeben, den Autorisierungs-Header so einrichten, dass er das JSON Web Token enthält.
Jetzt ist der Abmeldevorgang ziemlich einfach,
wenn wir das JSON Web Token zerstören, das wir auf der Clientseite haben,
wird der Client nicht mehr auf den Server zugreifen können.
Es ist also so einfach, wie
das JSON Web Token auf der Clientseite zum Abmelden dieses Clients zu zerstören.
Angesichts dieses Verständnisses
sehen wir uns also die Schritte an, die bei
der Benutzerauthentifizierung auf der Clientseite mit der Benutzerauthentifizierung beteiligt sind.
Um die Benutzerauthentifizierung auf der Clientseite zu behandeln,
sendet der Client eine Post-Anfrage an den Schrägstrich Benutzer Anmeldeendpunkt,
und der Text der Post-Anfrage enthält den Benutzernamen und das Passwort.
Wir verwenden in diesem Fall die Login-Authentifizierung.
Nun, für die Facebook-Authentifizierung, wieder,
das ist ein anderes Setup, das ich jetzt nicht diskutieren werde.
Der Anforderungstext, wie Sie für die
lokale Authentifizierung sehen, enthält jedoch den Benutzernamen und das Kennwort.
Wenn der Benutzer also erfolgreich auf der Serverseite authentifiziert wurde,
antwortet der Server dann an den
Client zurück, indem er das JSON-Web-Token in die Antwortnachricht einschließt.
Wenn der Client die Antwortnachricht von der Serverseite empfängt,
muss der Client dieses JSON-Web-Token erfassen und dann
das JSON-Web-Token im lokalen Speicher auf der Clientseite speichern.
Danach sollte der Client dieses Token in jede ausgehende Anforderung aufnehmen.
Also, wie wird das auf der Client-Seite erreicht?
In erster Linie müssen wir das JSON Web Token im lokalen Speicher speichern.
Dies wird nun innerhalb des Aktionserstellers erreicht, der den Benutzeranmeldeprozess verarbeitet.
Wenn also der Beitrag vom clientseitigen Induktionsersteller an den Server erfolgt,
enthält die Antwortnachricht das Token,
und dieses Token wird im Aktionsersteller gespeichert, der den Benutzeranmeldeprozess verarbeitet.
Jetzt danach, wenn eine Fetch-Anfrage abgeschlossen ist,
können wir den Autorisierungs-Header in der ausgehenden Fetch-Anfrage leicht einstellen.
Sobald sich der Client abmeldet,
wird das JSON-Web-Token auf der Clientseite zerstört.
Danach enthalten ausgehende Anforderungen
das JSON-Web-Token nicht mehr, da das JSON-Web-Token auf der Clientseite nicht vorhanden ist.
Dadurch verliert der Benutzer die Authentifizierung.
So werden wir den Login- und Abmeldeprozess auf der Clientseite behandeln.
Durch die Kommunikation mit dem Server und dann das JSON-Web-Token abrufen und
dann das JSON-Web-Token in jede ausgehende Anforderung einschließen.
Nun, mit diesem Verständnis, wie der Client und der Server interagieren,
gehen wir jetzt mit den nächsten zwei Übungen über.
Zunächst werden wir die Serverseite mit ein paar Ergänzungen aktualisieren
, so dass sie sich gut in unsere Client-Seite integrieren kann.
Danach werden wir die Client-Seite aktualisieren oder vielmehr werde ich Ihnen
eine vollwertige Client-Anwendung geben, die ich
von der früheren Reaktionskraft genommen und angepasst habe, aktualisiert.
Also, wir werden beide in den nächsten zwei Übungen behandeln,
und am Ende werden Sie verstehen, wie Sie Ihre Client- und Server-Seite integrieren können.