1 00:00:03,650 --> 00:00:06,795 Nachdem wir nun die Implementierung 2 00:00:06,795 --> 00:00:11,395 des REST-API-Servers mit Express und MongoDB in diesem Kurs abgeschlossen haben, 3 00:00:11,395 --> 00:00:14,990 ist der nächste sofortige Gedanke, der in Ihrem Kopf auftreten könnte, 4 00:00:14,990 --> 00:00:20,490 da wir bereits die Client-Anwendungen in den vorherigen Kursen entwickelt haben, 5 00:00:20,490 --> 00:00:24,930 wie integrieren wir die beiden zusammen, damit unsere -Clientanwendung in der Lage ist, 6 00:00:24,930 --> 00:00:30,880 mit dem vollwertigen REST-API-Server zu interagieren, den wir in diesem Kurs entwickelt haben? Das 7 00:00:30,880 --> 00:00:33,820 werden wir also in 8 00:00:33,820 --> 00:00:39,820 diesem Vortrag und den beiden Übungen, die dieser Vorlesung folgen, untersuchen. 9 00:00:39,820 --> 00:00:41,770 Am Ende dieser Lektion 10 00:00:41,770 --> 00:00:44,390 haben Sie also React Client, der in der 11 00:00:44,390 --> 00:00:47,330 Lage ist, mit dem Server zu kommunizieren, den Sie gerade in 12 00:00:47,330 --> 00:00:50,345 diesem Kurs entwickelt haben, und in der Lage sein wird, 13 00:00:50,345 --> 00:00:56,510 die vollwertige Client-Seite unserer gesamten Anwendung zu unterstützen. 14 00:00:56,510 --> 00:01:02,565 Auf diese Weise werden wir sehen, dass wir in 15 00:01:02,565 --> 00:01:07,795 diesem Kurs die komplette End-to-End-Anwendung von der Client-Seite bis zur Serverseite entwickelt haben. 16 00:01:07,795 --> 00:01:10,910 Um den Client und den Server zu integrieren, 17 00:01:10,910 --> 00:01:13,670 wie wir festgestellt haben, dass unser Server bereits 18 00:01:13,670 --> 00:01:17,525 implementiert ist, um die vollwertige REST-API zu unterstützen. 19 00:01:17,525 --> 00:01:19,220 Von unserer Client-Seite, 20 00:01:19,220 --> 00:01:20,720 unabhängig davon, ob es sich um den Winkel-Client, 21 00:01:20,720 --> 00:01:23,340 den ionischen Client oder den nativen Skriptclient handelt, 22 00:01:23,340 --> 00:01:28,240 interagieren sie alle mit dem Server über die REST-API-Endpunkte. 23 00:01:28,240 --> 00:01:33,630 Wenn der Client die Anforderung an den Server am REST-API-Endpunkt sendet, 24 00:01:33,630 --> 00:01:38,190 antwortet der Server mit den entsprechenden JSON-Daten zurück an den Client. 25 00:01:38,190 --> 00:01:44,225 Der Client kann dann die JSON-Daten verwenden, um die Ansichten für den Benutzer zu rendern. 26 00:01:44,225 --> 00:01:50,450 Angesichts dieses Verständnisses der Kommunikation zwischen dem Client und dem Server 27 00:01:50,450 --> 00:01:53,745 sollte die Integration ziemlich einfach sein. Nachdem 28 00:01:53,745 --> 00:01:58,475 wir nun die Benutzerauthentifizierung auf unserer Serverseite integriert haben, 29 00:01:58,475 --> 00:02:03,330 müssen wir unsere Client-Anwendungen nachrüsten, 30 00:02:03,330 --> 00:02:08,400 damit sie die Benutzerauthentifizierung auf der Serverseite durchführen können, 31 00:02:08,400 --> 00:02:12,200 indem sie die Anmeldeinformationen auf dem Server veröffentlichen und dann das 32 00:02:12,200 --> 00:02:16,010 Authentifizierungstoken von 33 00:02:16,010 --> 00:02:19,120 der Serverseite erhalten. und danach die Kommunikation mit dem Server 34 00:02:19,120 --> 00:02:23,700 einschließlich des Authentifizierungstoken in der Kopfzeile der Anforderungsnachrichten. 35 00:02:23,700 --> 00:02:27,050 All dies bedeutet also, dass wir kleinere Anpassungen sowohl 36 00:02:27,050 --> 00:02:31,345 am Client als auch am Server vornehmen müssen, damit die beiden miteinander kommunizieren können. 37 00:02:31,345 --> 00:02:36,530 Ein Aspekt, den ich in der Übung zuvor nicht behandelt habe, 38 00:02:36,530 --> 00:02:41,970 ist, wie der Server die Abfrageparameter handhabt, die von der Clientseite stammen. 39 00:02:41,970 --> 00:02:43,480 Also, wie wir erkannten, 40 00:02:43,480 --> 00:02:47,450 wenn die Client-Seite sendet eine Anfrage für 41 00:02:47,450 --> 00:02:53,035 ein vorgestelltes Gericht oder einen vorgestellten Führer oder eine vorgestellte Förderung, 42 00:02:53,035 --> 00:02:55,910 sahen wir, dass die URL enthält, 43 00:02:55,910 --> 00:02:59,590 Gerichte Fragezeichen Funktion ist gleich 44 00:02:59,590 --> 00:03:04,370 wahr in der Anfrage URL, die von der Client-Seite kommt. 45 00:03:04,370 --> 00:03:07,210 Jetzt 46 00:03:07,210 --> 00:03:09,585 haben wir in den Daten auf der Serverseite bereits gesehen, dass das Gericht, die 47 00:03:09,585 --> 00:03:15,370 Promotion oder der Führer das vorgestellte Flag bereits in den JSON-Daten enthält. 48 00:03:15,370 --> 00:03:18,649 Wenn diese Anforderung auf die Serverseite kommt, 49 00:03:18,649 --> 00:03:21,394 sollte der Server in der Lage sein, 50 00:03:21,394 --> 00:03:26,765 diesen Abfrageparameter aus der eingehenden Anfrage zu extrahieren und dann 51 00:03:26,765 --> 00:03:32,390 die Abfrage der 52 00:03:32,390 --> 00:03:39,950 MongoDB entsprechend durchzuführen und dann nur die Ergebnisse zu erhalten, bei denen dieses Feature-Flag auf true gesetzt ist. 53 00:03:39,950 --> 00:03:41,740 Also, um das zu tun, wie wir gesehen haben, 54 00:03:41,740 --> 00:03:47,075 ist die URL, die für das Senden der Anfrage an den Server verwendet wird, 55 00:03:47,075 --> 00:03:52,030 Schrägstrich Gerichte Fragezeichen gekennzeichnet ist gleich wahr. 56 00:03:52,030 --> 00:03:57,905 Also, so werden wir die Abfrageparameter auf unserer Serverseite liefern. 57 00:03:57,905 --> 00:04:02,610 Nun, wenn diese Informationen auf der Serverseite empfangen werden, 58 00:04:02,610 --> 00:04:07,430 haben wir jetzt gesehen, dass früher, als wir die Get Anfrage auf der Serverseite gemacht 59 00:04:07,430 --> 00:04:10,190 haben, wir einfach gesagt, Gerichte finden und dann würden wir 60 00:04:10,190 --> 00:04:13,135 alle Gerichte finden und sie dann zurückgeben, wenn 61 00:04:13,135 --> 00:04:19,745 die get Anfrage an die Schüssel Router Route Schrägstrich gesendet . 62 00:04:19,745 --> 00:04:25,185 Die gleiche Logik gilt sowohl für den Promo-Router als auch für den Leader Router. 63 00:04:25,185 --> 00:04:30,339 Wenn Sie nun einen Abfrageparameter wie diesen in die URL einfügen, 64 00:04:30,339 --> 00:04:35,980 wie wird unsere Serverseite in der Lage sein, diesen Abfrageparameter zu extrahieren? 65 00:04:35,980 --> 00:04:42,590 Wenn die eingehende Anforderung diesen Abfrageparameter an die eingehende URL angehängt hat, 66 00:04:42,590 --> 00:04:47,375 verarbeitet der Express-Server diesen automatisch und wandelt ihn in 67 00:04:47,375 --> 00:04:54,445 ein JSON-Objekt um, das in eine Anforderungsnachricht geladen wird, die auf der Serverseite eingeht. 68 00:04:54,445 --> 00:05:00,710 Nun ist dies serverseitig in Form von req.query verfügbar. 69 00:05:00,710 --> 00:05:06,545 Also, alle Abfrageparameter, die Sie in die URL einfügen, werden in 70 00:05:06,545 --> 00:05:11,480 entsprechende JSON-Objekte mit den Informationen umgewandelt, die 71 00:05:11,480 --> 00:05:16,880 hier festgelegt sind und dann auf das Anforderungsobjekt auf der Serverseite geladen werden. 72 00:05:16,880 --> 00:05:19,940 Also, durch die Verwendung von req.query auf der Serverseite, 73 00:05:19,940 --> 00:05:23,625 werden wir in der Lage sein, diese Abfrageparameter zu erhalten. 74 00:05:23,625 --> 00:05:27,935 Also, wenn Sie eine get-Anfrage auf der Serverseite ausführen, sagen Sie 75 00:05:27,935 --> 00:05:34,115 dishes.find und dann fügen Sie die req.query in die Suche dort ein. 76 00:05:34,115 --> 00:05:38,960 Wenn also die MongoDB 77 00:05:38,960 --> 00:05:44,120 abgefragt wird, 78 00:05:44,120 --> 00:05:50,390 werden nur die Datensätze oder nur die Dokumente, für die das Featured auf true gesetzt ist, aus der MongoDB extrahiert und 79 00:05:50,390 --> 00:05:57,020 uns innerhalb dieser get-Methode hier zurückgegeben und können dann an die Client-Seite zurückgegeben werden. 80 00:05:57,020 --> 00:06:05,270 Dies ist also so einfach wie bei der Verarbeitung der Abfrageparameter auf unserer Serverseite. 81 00:06:05,270 --> 00:06:10,645 Also, dieses Update werden wir sowohl mit dem Dish Router, 82 00:06:10,645 --> 00:06:16,880 dem Promo-Router als auch dem Leader Router auf unserer Serverseite tun. 83 00:06:16,880 --> 00:06:18,430 Der nächste Teil ist 84 00:06:18,430 --> 00:06:20,545 natürlich die Benutzerauthentifizierung. 85 00:06:20,545 --> 00:06:22,060 Also, wie wir festgestellt haben, 86 00:06:22,060 --> 00:06:24,150 haben wir auf der Serverseite bereits 87 00:06:24,150 --> 00:06:29,450 diese REST-API-Endpunkte, die für die Benutzerauthentifizierung nützlich sind, 88 00:06:29,450 --> 00:06:33,260 insbesondere wenn Sie einen Beitrag machen, um Benutzer 89 00:06:33,260 --> 00:06:37,100 mit dem Benutzernamen und Passwort zu schrägen, 90 00:06:37,100 --> 00:06:41,675 dann werden Sie in der Lage sein, den Benutzer auf dem Server zu authentifizieren Seite. 91 00:06:41,675 --> 00:06:46,080 Wenn der Benutzer nun auf der Serverseite erfolgreich authentifiziert wurde, 92 00:06:46,080 --> 00:06:50,584 enthält die Antwortnachricht, die von der Serverseite kommt, 93 00:06:50,584 --> 00:06:58,880 das JSON-Web-Token in den Antworttext der eingehenden Antwortnachricht von der Serverseite. 94 00:06:58,880 --> 00:07:00,350 Also, auf der Client-Seite 95 00:07:00,350 --> 00:07:04,700 sollten wir in der Lage sein, dieses Token zu extrahieren und dann dieses Token später zu verwenden. 96 00:07:04,700 --> 00:07:08,210 Wenn also der Client die Antwortnachricht von 97 00:07:08,210 --> 00:07:12,560 der Serverseite empfängt und der Benutzer erfolgreich auf der Serverseite authentifiziert wurde, 98 00:07:12,560 --> 00:07:15,220 enthält die Antwortnachricht das JSON-Web-Token, 99 00:07:15,220 --> 00:07:16,950 das extrahiert werden muss, 100 00:07:16,950 --> 00:07:20,780 und danach sollte der Client dieses JSON-Web-Token in 101 00:07:20,780 --> 00:07:26,200 die Autorisierungs-Header für jede ausgehende Anforderung von der Client-Seite. 102 00:07:26,200 --> 00:07:31,205 Dies wird erreicht, indem das JSON-Web-Token im lokalen Speicher gespeichert wird. 103 00:07:31,205 --> 00:07:35,155 Danach 104 00:07:35,155 --> 00:07:40,365 können wir für jede Abrufanforderung, die wir ausgeben, den Autorisierungs-Header so einrichten, dass er das JSON Web Token enthält. 105 00:07:40,365 --> 00:07:43,815 Jetzt ist der Abmeldevorgang ziemlich einfach, 106 00:07:43,815 --> 00:07:47,865 wenn wir das JSON Web Token zerstören, das wir auf der Clientseite haben, 107 00:07:47,865 --> 00:07:51,210 wird der Client nicht mehr auf den Server zugreifen können. 108 00:07:51,210 --> 00:07:53,930 Es ist also so einfach, wie 109 00:07:53,930 --> 00:07:58,180 das JSON Web Token auf der Clientseite zum Abmelden dieses Clients zu zerstören. 110 00:07:58,180 --> 00:08:00,530 Angesichts dieses Verständnisses 111 00:08:00,530 --> 00:08:04,175 sehen wir uns also die Schritte an, die bei 112 00:08:04,175 --> 00:08:09,840 der Benutzerauthentifizierung auf der Clientseite mit der Benutzerauthentifizierung beteiligt sind. 113 00:08:09,840 --> 00:08:13,085 Um die Benutzerauthentifizierung auf der Clientseite zu behandeln, 114 00:08:13,085 --> 00:08:19,000 sendet der Client eine Post-Anfrage an den Schrägstrich Benutzer Anmeldeendpunkt, 115 00:08:19,000 --> 00:08:24,190 und der Text der Post-Anfrage enthält den Benutzernamen und das Passwort. 116 00:08:24,190 --> 00:08:26,720 Wir verwenden in diesem Fall die Login-Authentifizierung. 117 00:08:26,720 --> 00:08:28,695 Nun, für die Facebook-Authentifizierung, wieder, 118 00:08:28,695 --> 00:08:32,425 das ist ein anderes Setup, das ich jetzt nicht diskutieren werde. 119 00:08:32,425 --> 00:08:35,570 Der Anforderungstext, wie Sie für die 120 00:08:35,570 --> 00:08:38,780 lokale Authentifizierung sehen, enthält jedoch den Benutzernamen und das Kennwort. 121 00:08:38,780 --> 00:08:43,220 Wenn der Benutzer also erfolgreich auf der Serverseite authentifiziert wurde, 122 00:08:43,220 --> 00:08:46,460 antwortet der Server dann an den 123 00:08:46,460 --> 00:08:51,490 Client zurück, indem er das JSON-Web-Token in die Antwortnachricht einschließt. 124 00:08:51,490 --> 00:08:56,150 Wenn der Client die Antwortnachricht von der Serverseite empfängt, 125 00:08:56,150 --> 00:09:00,320 muss der Client dieses JSON-Web-Token erfassen und dann 126 00:09:00,320 --> 00:09:05,080 das JSON-Web-Token im lokalen Speicher auf der Clientseite speichern. 127 00:09:05,080 --> 00:09:11,300 Danach sollte der Client dieses Token in jede ausgehende Anforderung aufnehmen. 128 00:09:11,300 --> 00:09:14,495 Also, wie wird das auf der Client-Seite erreicht? 129 00:09:14,495 --> 00:09:20,285 In erster Linie müssen wir das JSON Web Token im lokalen Speicher speichern. 130 00:09:20,285 --> 00:09:25,670 Dies wird nun innerhalb des Aktionserstellers erreicht, der den Benutzeranmeldeprozess verarbeitet. 131 00:09:25,670 --> 00:09:32,685 Wenn also der Beitrag vom clientseitigen Induktionsersteller an den Server erfolgt, 132 00:09:32,685 --> 00:09:36,020 enthält die Antwortnachricht das Token, 133 00:09:36,020 --> 00:09:41,540 und dieses Token wird im Aktionsersteller gespeichert, der den Benutzeranmeldeprozess verarbeitet. 134 00:09:41,540 --> 00:09:45,875 Jetzt danach, wenn eine Fetch-Anfrage abgeschlossen ist, 135 00:09:45,875 --> 00:09:52,829 können wir den Autorisierungs-Header in der ausgehenden Fetch-Anfrage leicht einstellen. 136 00:09:52,829 --> 00:09:56,005 Sobald sich der Client abmeldet, 137 00:09:56,005 --> 00:09:59,930 wird das JSON-Web-Token auf der Clientseite zerstört. 138 00:09:59,930 --> 00:10:03,050 Danach enthalten ausgehende Anforderungen 139 00:10:03,050 --> 00:10:07,490 das JSON-Web-Token nicht mehr, da das JSON-Web-Token auf der Clientseite nicht vorhanden ist. 140 00:10:07,490 --> 00:10:10,790 Dadurch verliert der Benutzer die Authentifizierung. 141 00:10:10,790 --> 00:10:17,455 So werden wir den Login- und Abmeldeprozess auf der Clientseite behandeln. 142 00:10:17,455 --> 00:10:21,890 Durch die Kommunikation mit dem Server und dann das JSON-Web-Token abrufen und 143 00:10:21,890 --> 00:10:26,185 dann das JSON-Web-Token in jede ausgehende Anforderung einschließen. 144 00:10:26,185 --> 00:10:31,570 Nun, mit diesem Verständnis, wie der Client und der Server interagieren, 145 00:10:31,570 --> 00:10:35,540 gehen wir jetzt mit den nächsten zwei Übungen über. 146 00:10:35,540 --> 00:10:40,410 Zunächst werden wir die Serverseite mit ein paar Ergänzungen aktualisieren 147 00:10:40,410 --> 00:10:45,550 , so dass sie sich gut in unsere Client-Seite integrieren kann. 148 00:10:45,550 --> 00:10:50,075 Danach werden wir die Client-Seite aktualisieren oder vielmehr werde ich Ihnen 149 00:10:50,075 --> 00:10:54,200 eine vollwertige Client-Anwendung geben, die ich 150 00:10:54,200 --> 00:10:58,875 von der früheren Reaktionskraft genommen und angepasst habe, aktualisiert. 151 00:10:58,875 --> 00:11:03,080 Also, wir werden beide in den nächsten zwei Übungen behandeln, 152 00:11:03,080 --> 00:11:09,460 und am Ende werden Sie verstehen, wie Sie Ihre Client- und Server-Seite integrieren können.