1 00:00:01,670 --> 00:00:04,320 ‫Kursleiter: Jetzt, da wir wissen, was Express ist, sind 2 00:00:04,320 --> 00:00:07,550 ‫wir fast so weit, mit der Erstellung unserer API zu beginnen. 3 00:00:07,550 --> 00:00:08,890 ‫Aber bevor wir 4 00:00:08,890 --> 00:00:12,300 ‫das tun, muss ich kurz über APIs auf einer höheren 5 00:00:12,300 --> 00:00:13,910 ‫Ebene sprechen und, was 6 00:00:13,910 --> 00:00:16,370 ‫noch wichtiger ist, Ihnen die REST-Architektur 7 00:00:16,370 --> 00:00:19,640 ‫vorstellen, die heute die am häufigsten verwendete API-Architektur ist. 8 00:00:19,640 --> 00:00:23,270 ‫Auf diese Weise wissen wir tatsächlich, was wir bauen. 9 00:00:23,270 --> 00:00:25,710 ‫Daher ist es äußerst wichtig, die Inhalte in 10 00:00:25,710 --> 00:00:27,860 ‫diesem Video zu verstehen, bevor wir 11 00:00:27,860 --> 00:00:30,580 ‫fortfahren, damit wir tatsächlich wissen, was wir im 12 00:00:30,580 --> 00:00:32,603 ‫weiteren Verlauf des Kurses aufbauen. 13 00:00:33,630 --> 00:00:34,890 ‫API steht 14 00:00:34,890 --> 00:00:38,390 ‫in erster Linie für Application Programming Interface und auf 15 00:00:38,390 --> 00:00:40,130 ‫sehr hohem Niveau ist 16 00:00:40,130 --> 00:00:43,150 ‫es im Grunde eine Software, die von einer 17 00:00:43,150 --> 00:00:45,270 ‫anderen Software verwendet werden kann, 18 00:00:45,270 --> 00:00:48,213 ‫um Anwendungen zu ermöglichen, miteinander zu kommunizieren. 19 00:00:49,080 --> 00:00:51,420 ‫Wir haben schon früher über 20 00:00:51,420 --> 00:00:53,780 ‫APIs gesprochen, genauer gesagt über Web-APIs, bei 21 00:00:53,780 --> 00:00:56,300 ‫denen wir einfach eine App erstellt haben, 22 00:00:56,300 --> 00:00:59,640 ‫die Daten an einen Client sendet, wenn eine Anfrage eingeht. 23 00:00:59,640 --> 00:01:02,530 ‫Stellen Sie sich vor, unsere App läuft auf einem Server 24 00:01:02,530 --> 00:01:04,060 ‫und wir haben einen Client. 25 00:01:04,060 --> 00:01:08,020 ‫Tatsächlich haben wir also effektiv zwei Softwarekomponenten, die 26 00:01:08,020 --> 00:01:10,250 ‫miteinander kommunizieren, oder? 27 00:01:10,250 --> 00:01:13,550 ‫Und das ist die Art von API, die wir in diesem Kurs erstellen werden. 28 00:01:13,550 --> 00:01:17,470 ‫Und ich denke, es ist die am weitesten verbreitete Art von API auf dem Markt. 29 00:01:17,470 --> 00:01:21,970 ‫Tatsächlich werden APIs jedoch nicht nur zum Senden von Daten verwendet und 30 00:01:21,970 --> 00:01:25,493 ‫haben nicht immer mit Webentwicklung oder JavaScript zu tun. 31 00:01:26,400 --> 00:01:29,500 ‫Die Anwendung in API kann tatsächlich 32 00:01:29,500 --> 00:01:32,710 ‫viele verschiedene Dinge bedeuten, solange die 33 00:01:32,710 --> 00:01:35,050 ‫Software relativ eigenständig ist. 34 00:01:35,050 --> 00:01:35,900 ‫Nehmen Sie 35 00:01:35,900 --> 00:01:38,870 ‫zum Beispiel das Node File System oder die HTTP-Module. 36 00:01:38,870 --> 00:01:42,010 ‫Wir können sagen, dass es sich um kleine Softwarestücke 37 00:01:42,010 --> 00:01:43,110 ‫handelt und wir 38 00:01:43,110 --> 00:01:46,970 ‫sie verwenden können, wir können mit ihnen über ihre API interagieren. 39 00:01:46,970 --> 00:01:47,803 ‫Wenn 40 00:01:47,803 --> 00:01:51,150 ‫wir beispielsweise die Readfile-Funktion des FS-Moduls verwenden, 41 00:01:51,150 --> 00:01:54,020 ‫verwenden wir tatsächlich die FS-API. 42 00:01:54,020 --> 00:01:57,380 ‫Deshalb hört man manchmal den Begriff Node-APIs. 43 00:01:57,380 --> 00:02:01,090 ‫Und das bezieht sich normalerweise einfach auf die Kernknotenmodule, mit 44 00:02:01,090 --> 00:02:02,920 ‫denen wir interagieren können. 45 00:02:02,920 --> 00:02:05,670 ‫Oder wenn wir die DOM-Manipulation im Browser 46 00:02:05,670 --> 00:02:08,650 ‫durchführen, verwenden wir nicht wirklich die JavaScript-Sprache selbst, 47 00:02:08,650 --> 00:02:12,440 ‫sondern die DOM-API, die der Browser uns zur Verfügung stellt, damit 48 00:02:12,440 --> 00:02:14,280 ‫wir darauf zugreifen können. 49 00:02:14,280 --> 00:02:15,930 ‫Oder noch ein anderes Beispiel, 50 00:02:15,930 --> 00:02:19,080 ‫sagen wir, wir erstellen eine Klasse in einer beliebigen Programmiersprache 51 00:02:19,080 --> 00:02:21,940 ‫wie Java und fügen ihr dann einige öffentliche Methoden 52 00:02:21,940 --> 00:02:23,420 ‫oder Eigenschaften hinzu. 53 00:02:23,420 --> 00:02:26,860 ‫Diese Methoden sind dann die API jedes aus 54 00:02:26,860 --> 00:02:29,450 ‫dieser Klasse erstellten Objekts, da wir 55 00:02:29,450 --> 00:02:31,890 ‫anderen Softwareteilen die Möglichkeit geben, 56 00:02:31,890 --> 00:02:35,420 ‫mit unserer ursprünglichen Software, in diesem Fall den 57 00:02:35,420 --> 00:02:37,278 ‫Objekten, zu interagieren. 58 00:02:37,278 --> 00:02:40,810 ‫Sie sehen, API hat tatsächlich eine breitere Bedeutung als 59 00:02:40,810 --> 00:02:42,810 ‫nur das Erstellen von Web-APIs. 60 00:02:42,810 --> 00:02:47,420 ‫In Ordung? Wie auch immer, eine Web-API ist 61 00:02:47,420 --> 00:02:50,340 ‫für uns im Kontext von Note am wichtigsten. 62 00:02:50,340 --> 00:02:53,050 ‫Werfen wir nun einen Blick auf die REST-Architektur, um 63 00:02:53,050 --> 00:02:54,203 ‫APIs zu erstellen. 64 00:02:55,820 --> 00:02:59,910 ‫REST, was für Representational States Transfer steht, ist im Grunde 65 00:02:59,910 --> 00:03:03,930 ‫eine Möglichkeit, Web-APIs auf logische Weise zu erstellen und sie 66 00:03:03,930 --> 00:03:06,060 ‫einfach zu nutzen, denn 67 00:03:06,060 --> 00:03:09,420 ‫denken Sie daran, dass wir eine API für 68 00:03:09,420 --> 00:03:12,023 ‫uns selbst oder für andere erstellen, okay? 69 00:03:12,023 --> 00:03:15,640 ‫Wir möchten den Prozess der tatsächlichen Nutzung der API für den 70 00:03:15,640 --> 00:03:17,633 ‫Benutzer so reibungslos wie möglich gestalten. 71 00:03:18,490 --> 00:03:20,830 ‫Um nun RESTful-APIs zu erstellen, 72 00:03:20,830 --> 00:03:24,180 ‫d. h. APIs, die der REST-Architektur folgen, müssen 73 00:03:24,180 --> 00:03:26,660 ‫wir nur ein paar Prinzipien befolgen. 74 00:03:26,660 --> 00:03:31,240 ‫Zuerst müssen wir unsere API in logische Ressourcen aufteilen. 75 00:03:31,240 --> 00:03:33,860 ‫Diese Ressourcen sollten dann 76 00:03:33,860 --> 00:03:35,900 ‫exponiert, das heißt 77 00:03:35,900 --> 00:03:39,420 ‫über strukturierte, ressourcenbasierte URLs verfügbar gemacht werden. 78 00:03:39,420 --> 00:03:41,460 ‫Um verschiedene Aktionen an Daten 79 00:03:41,460 --> 00:03:44,677 ‫durchzuführen, wie das Lesen oder Erstellen oder Löschen 80 00:03:44,677 --> 00:03:49,677 ‫von Daten, sollte die API die richtigen HTP-Methoden und nicht die URL verwenden. 81 00:03:50,270 --> 00:03:53,210 ‫Nun sollten die Daten, die wir tatsächlich an 82 00:03:53,210 --> 00:03:55,420 ‫den Client zurücksenden oder die 83 00:03:55,420 --> 00:03:58,030 ‫wir vom Client erhalten haben, normalerweise 84 00:03:58,030 --> 00:04:01,010 ‫das JSON-Datenformat verwenden, für das einige Formatierungsstandards gelten. 85 00:04:01,010 --> 00:04:04,500 ‫Schließlich ist ein weiteres wichtiges Prinzip von 86 00:04:04,500 --> 00:04:07,560 ‫REST-APIs, dass sie zustandslos sein müssen. 87 00:04:07,560 --> 00:04:09,950 ‫Dies ist also ein sehr breiter Überblick. 88 00:04:09,950 --> 00:04:12,030 ‫Lassen Sie uns nun nacheinander über 89 00:04:12,030 --> 00:04:15,310 ‫diese Prinzipien sprechen, beginnend mit den Ressourcen und der Verwendung 90 00:04:15,310 --> 00:04:17,810 ‫der Nators-API, die wir in diesem Kurs 91 00:04:17,810 --> 00:04:19,803 ‫als Beispiel hier erstellen werden. 92 00:04:20,960 --> 00:04:24,910 ‫Die wichtigste Abstraktion von Informationen in REST ist eine Ressource, 93 00:04:24,910 --> 00:04:27,450 ‫und daher sollten alle Daten, 94 00:04:27,450 --> 00:04:32,040 ‫die wir in der API teilen möchten, in logische Ressourcen unterteilt werden. 95 00:04:32,040 --> 00:04:34,350 ‫Was ist nun eigentlich eine Ressource? 96 00:04:34,350 --> 00:04:36,380 ‫Nun, im Kontext von 97 00:04:36,380 --> 00:04:39,520 ‫REST ist es ein Objekt oder eine Darstellung 98 00:04:39,520 --> 00:04:42,020 ‫von etwas, dem einige Daten zugeordnet sind. 99 00:04:42,020 --> 00:04:42,853 ‫Zum 100 00:04:42,853 --> 00:04:45,570 ‫Beispiel Touren oder Benutzer oder Bewertungen im 101 00:04:45,570 --> 00:04:48,020 ‫Fall des Beispiels, dem wir folgen. 102 00:04:48,020 --> 00:04:50,730 ‫Im Grunde können also alle Informationen, die benannt werden 103 00:04:50,730 --> 00:04:53,040 ‫können, eine Ressource sein, in Ordnung? 104 00:04:53,040 --> 00:04:56,050 ‫Es muss nur ein Name sein, kein Verb. 105 00:04:56,050 --> 00:04:57,690 ‫Jetzt müssen wir 106 00:04:57,690 --> 00:04:59,480 ‫die Daten mithilfe einiger strukturierter 107 00:04:59,480 --> 00:05:02,520 ‫URLs bereitstellen, d. h. verfügbar machen, an die 108 00:05:02,520 --> 00:05:04,890 ‫der Client eine Anfrage senden kann. 109 00:05:04,890 --> 00:05:07,611 ‫Zum Beispiel so etwas. 110 00:05:07,611 --> 00:05:10,740 ‫Diese gesamte Adresse wird als URL 111 00:05:10,740 --> 00:05:14,323 ‫bezeichnet und diese /addNewTour wird als API-Endpunkt bezeichnet. 112 00:05:15,269 --> 00:05:17,840 ‫Unsere API wird viele verschiedene Endpunkte haben, 113 00:05:17,840 --> 00:05:20,560 ‫genau wie diese fiktiven Endpunkte, die ich hier 114 00:05:20,560 --> 00:05:23,730 ‫habe, von denen jeder unterschiedliche Daten an den Client 115 00:05:23,730 --> 00:05:26,150 ‫zurücksendet oder auch unterschiedliche Aktionen ausführt. 116 00:05:26,150 --> 00:05:28,440 ‫Mit diesen Endpunkten stimmt hier 117 00:05:28,440 --> 00:05:31,750 ‫tatsächlich etwas sehr nicht, weil sie wirklich nicht 118 00:05:31,750 --> 00:05:34,827 ‫der dritten Regel folgen, die besagt, dass 119 00:05:34,827 --> 00:05:39,110 ‫wir die HTTP-Methoden nur verwenden sollten, um Aktionen mit Daten durchzuführen. 120 00:05:39,110 --> 00:05:42,360 ‫Endpunkte sollten also nur unsere Ressourcen enthalten und nicht 121 00:05:42,360 --> 00:05:45,070 ‫die Aktionen, die auf ihnen ausgeführt werden 122 00:05:45,070 --> 00:05:48,313 ‫können, da die Wartung schnell zu einem Albtraum wird. 123 00:05:49,644 --> 00:05:54,210 ‫Wie sollten wir diese HTTP-Methoden in der Praxis verwenden? 124 00:05:54,210 --> 00:05:56,120 ‫Sehen wir uns an, 125 00:05:56,120 --> 00:05:59,620 ‫wie diese Endpunkte tatsächlich aussehen sollten, beginnend mit /getTour. 126 00:05:59,620 --> 00:06:03,290 ‫Dieser Endpunkt /getTour dient also zum Abrufen von Daten zu einer Tour. 127 00:06:03,290 --> 00:06:06,240 ‫Also sollten wir einfach den Endpunkt /tours benennen und 128 00:06:06,240 --> 00:06:08,740 ‫die Daten senden, wenn eine Get-Anforderung an 129 00:06:08,740 --> 00:06:10,430 ‫diesen Endpunkt gestellt wird. 130 00:06:10,430 --> 00:06:11,650 ‫Mit anderen 131 00:06:11,650 --> 00:06:14,730 ‫Worten, wenn ein Client eine GET-HTTP-Methode verwendet, 132 00:06:14,730 --> 00:06:16,700 ‫um auf den Endpunkt zuzugreifen. 133 00:06:16,700 --> 00:06:17,870 ‫Und genau 134 00:06:17,870 --> 00:06:20,220 ‫so haben wir nur Ressourcen im 135 00:06:20,220 --> 00:06:23,670 ‫Endpunkt oder in der URL und keine Verben, weil 136 00:06:23,670 --> 00:06:26,870 ‫das Verb jetzt in der HTTP-Methode ist, richtig? 137 00:06:26,870 --> 00:06:27,703 ‫Übrigens 138 00:06:27,703 --> 00:06:30,490 ‫ist es üblich, den Ressourcennamen immer im 139 00:06:30,490 --> 00:06:34,820 ‫Plural zu verwenden, weshalb ich hier /tours und nicht /tour habe. 140 00:06:34,820 --> 00:06:37,790 ‫Nun, die Konvention ist, dass wir beim Aufrufen 141 00:06:37,790 --> 00:06:41,820 ‫dieses Endpunkts alle Touren zurückbekommen, die sich in einer Datenbank befinden, okay? 142 00:06:41,820 --> 00:06:44,820 ‫Aber wenn wir nur die Tour mit einem wollen, dann habe ich. D. sagen wir sieben, wir 143 00:06:44,820 --> 00:06:48,960 ‫fügen diese sieben nach einem weiteren Schrägstrich oder in einer Suchanfrage hinzu. 144 00:06:48,960 --> 00:06:50,580 ‫Oder es könnte statt des I auch der Name einer Tour sein. D. oder eine andere eindeutige Kennung. 145 00:06:50,580 --> 00:06:53,490 ‫Das Detail ist an dieser Stelle nicht wirklich wichtig, in Ordnung? 146 00:06:53,490 --> 00:06:55,410 ‫Später werde ich Ihnen zeigen, 147 00:06:55,410 --> 00:06:58,300 ‫wie einfach es ist, diese Art von Logik mit 148 00:06:58,300 --> 00:07:01,180 ‫Express tatsächlich umzusetzen, denn genau hier glänzt Express wirklich. 149 00:07:01,180 --> 00:07:03,410 ‫Die erste HTTP-Methode oder das 150 00:07:03,410 --> 00:07:06,733 ‫erste Verb, auf das wir antworten können, ist GET und 151 00:07:07,606 --> 00:07:10,460 ‫wird verwendet, um den Lesevorgang für Daten auszuführen. 152 00:07:10,460 --> 00:07:12,530 ‫Wenn der Kunde als nächstes 153 00:07:12,530 --> 00:07:16,290 ‫eine neue Ressource in unserer Datenbank erstellen möchte, in 154 00:07:16,290 --> 00:07:18,290 ‫diesem Beispiel eine 155 00:07:18,290 --> 00:07:21,450 ‫neue Tour, sollte die POST-Methode verwendet werden. 156 00:07:21,450 --> 00:07:23,200 ‫Wir haben also vorhin erfahren, dass eine 157 00:07:23,200 --> 00:07:25,510 ‫POST-Anfrage verwendet werden kann, um Daten an den Server 158 00:07:25,510 --> 00:07:28,490 ‫zu senden, und daher ist es sinnvoll, POST zu verwenden, um 159 00:07:28,490 --> 00:07:30,230 ‫neue Ressourcen zu erstellen, oder? 160 00:07:30,230 --> 00:07:32,270 ‫In diesem Fall normalerweise kein Ich. D. gesendet wird, da der Server 161 00:07:32,270 --> 00:07:38,530 ‫automatisch die I. 162 00:07:38,530 --> 00:07:38,530 ‫D. für die neue Ressource. 163 00:07:38,530 --> 00:07:40,860 ‫Auf jeden Fall ist es hier wirklich wichtig zu beachten, dass der Endpunktname genau derselbe 164 00:07:40,860 --> 00:07:42,948 ‫Name ist wie zuvor. 165 00:07:42,948 --> 00:07:46,090 ‫Der einzige Unterschied ist wirklich 166 00:07:46,090 --> 00:07:50,289 ‫die HTP-Methode, die für die Anfrage verwendet wird. 167 00:07:50,289 --> 00:07:53,870 ‫Wenn mit GET auf den Endpunkt /tours zugegriffen wird, senden 168 00:07:53,870 --> 00:07:55,960 ‫wir Daten an den Client. 169 00:07:55,960 --> 00:07:59,410 ‫Wenn jedoch mit POST auf denselben Endpunkt zugegriffen wird, erwarten 170 00:07:59,410 --> 00:08:01,460 ‫wir, dass Daten mit 171 00:08:01,460 --> 00:08:04,060 ‫einer Anfrage eingehen, damit wir dann auf 172 00:08:04,060 --> 00:08:06,550 ‫der Serverseite eine neue Ressource erstellen können. 173 00:08:06,550 --> 00:08:08,760 ‫Das ist also wirklich das Schöne daran, nur HTTP-Methoden zu 174 00:08:08,760 --> 00:08:10,330 ‫verwenden, anstatt mit Verben in Endpunktnamen herumzuspielen. 175 00:08:10,330 --> 00:08:14,460 ‫Auch hier würde es wirklich sehr schnell unüberschaubar werden. 176 00:08:14,460 --> 00:08:17,480 ‫In Ordnung, als nächstes sollte 177 00:08:17,480 --> 00:08:21,210 ‫es auch die Möglichkeit geben, Ressourcen zu aktualisieren. 178 00:08:21,210 --> 00:08:23,620 ‫Dazu sollte entweder eine PUT- oder 179 00:08:23,620 --> 00:08:26,390 ‫eine PATCH-Anfrage an den Endpunkt gestellt 180 00:08:26,390 --> 00:08:27,310 ‫werden. 181 00:08:27,310 --> 00:08:29,550 ‫Der Unterschied besteht darin, dass der 182 00:08:29,550 --> 00:08:31,550 ‫Client bei PUT das gesamte 183 00:08:31,550 --> 00:08:33,750 ‫aktualisierte Objekt senden soll, während bei 184 00:08:33,750 --> 00:08:37,280 ‫PATCH nur der Teil des Objekts gesendet werden soll, der 185 00:08:37,280 --> 00:08:38,370 ‫geändert wurde. 186 00:08:38,370 --> 00:08:40,967 ‫Beide haben jedoch die Möglichkeit, Daten an 187 00:08:40,967 --> 00:08:43,060 ‫den Server zu senden. 188 00:08:43,060 --> 00:08:45,140 ‫Eigentlich ein bisschen wie POST, aber mit einer anderen Absicht. 189 00:08:45,140 --> 00:08:46,750 ‫POST ist also das 190 00:08:46,750 --> 00:08:50,750 ‫Erstellen einer neuen Ressource, während PUT oder PATCH verwendet werden, um 191 00:08:50,750 --> 00:08:53,070 ‫eine vorhandene Ressource zu aktualisieren, und 192 00:08:53,070 --> 00:08:55,370 ‫so macht es dann den Unterschied. 193 00:08:55,370 --> 00:08:57,500 ‫Und schließlich gibt es 194 00:08:57,500 --> 00:08:59,660 ‫für die Abfallressource die HTTP-Methode DELETE. 195 00:08:59,660 --> 00:09:02,110 ‫Wieder das I. D. oder eine andere eindeutige Kennung der 196 00:09:02,110 --> 00:09:05,110 ‫zu löschenden Ressource sollte Teil der URL 197 00:09:05,110 --> 00:09:08,010 ‫sein. 198 00:09:08,010 --> 00:09:10,120 ‫Um diese Art von Anfrage 199 00:09:10,120 --> 00:09:11,820 ‫tatsächlich ausführen zu können, 200 00:09:11,820 --> 00:09:14,560 ‫muss der Client nun normalerweise authentifiziert werden. 201 00:09:14,560 --> 00:09:16,610 ‫Melden Sie sich also grundsätzlich bei Ihrer App an, okay? 202 00:09:16,610 --> 00:09:18,620 ‫Aber das ist natürlich ein Thema für viel später. 203 00:09:18,620 --> 00:09:21,670 ‫Dies sind also die fünf HTTP-Methoden, auf 204 00:09:21,670 --> 00:09:24,349 ‫die wir beim Erstellen unserer 205 00:09:24,349 --> 00:09:27,080 ‫RESTful-APIs reagieren können und sollten, damit 206 00:09:27,080 --> 00:09:29,320 ‫der Client die 207 00:09:29,320 --> 00:09:31,570 ‫vier grundlegenden CRUD-Operationen ausführen kann. 208 00:09:31,570 --> 00:09:33,270 ‫CRUD steht also für Create, Read, Update und Delete. 209 00:09:33,270 --> 00:09:36,290 ‫Und Sie werden diesen Begriff 210 00:09:36,290 --> 00:09:40,730 ‫ständig im Zusammenhang mit APIs und Datenbanken sehen. 211 00:09:40,730 --> 00:09:42,590 ‫Und Sie sehen, dass diese 212 00:09:42,590 --> 00:09:45,200 ‫HTTP-Methoden den grundlegenden CRUD-Operationen recht gut zugeordnet sind. 213 00:09:45,200 --> 00:09:47,490 ‫Nun, es könnte Aktionen geben, 214 00:09:47,490 --> 00:09:51,330 ‫die nicht CRUD sind, und in diesem Fall müssen 215 00:09:51,330 --> 00:09:54,410 ‫wir nur mit unseren Eingaben kreativ werden. 216 00:09:54,410 --> 00:09:55,460 ‫Zum Beispiel eine 217 00:09:55,460 --> 00:09:58,120 ‫Anmeldung oder ein Suchvorgang, diese beziehen sich nicht 218 00:09:58,120 --> 00:09:58,953 ‫wirklich 219 00:09:58,953 --> 00:10:01,010 ‫auf eine bestimmte Ressource und sind 220 00:10:01,010 --> 00:10:04,361 ‫auch keine CRUD-Vorgänge, aber wir können trotzdem Endpunkte dafür erstellen. 221 00:10:04,361 --> 00:10:06,630 ‫Zum Beispiel wie /login oder /search. 222 00:10:06,630 --> 00:10:09,240 ‫Aber wir werden später mehr über diese Fälle in der Praxis sprechen. 223 00:10:09,240 --> 00:10:12,530 ‫Und um diesen Teil jetzt abzuschließen, denken 224 00:10:12,530 --> 00:10:16,350 ‫Sie daran, dass wir auf der letzten Folie zwei 225 00:10:16,350 --> 00:10:18,290 ‫andere verrückte Endpunktnamen 226 00:10:18,290 --> 00:10:21,330 ‫hatten, die zwei Ressourcen gleichzeitig beinhalteten, richtig? 227 00:10:21,330 --> 00:10:23,870 ‫Und auch das ist mit REST kein Problem. 228 00:10:23,870 --> 00:10:26,780 ‫/getToursByUser kann also 229 00:10:26,780 --> 00:10:29,888 ‫einfach in /users/tours übersetzt werden, 230 00:10:29,888 --> 00:10:33,810 ‫in diesem Fall Benutzer Nummer drei. 231 00:10:33,810 --> 00:10:36,210 ‫Dieser spezielle Endpunkt hier könnte also Daten 232 00:10:36,210 --> 00:10:38,440 ‫über alle Touren senden, die Benutzer 233 00:10:38,440 --> 00:10:40,200 ‫Nummer drei gebucht hat. 234 00:10:40,200 --> 00:10:42,340 ‫Macht Sinn? 235 00:10:42,340 --> 00:10:44,580 ‫Oder im Falle des Löschens könnte es 236 00:10:44,580 --> 00:10:45,519 ‫eine Löschanforderung 237 00:10:45,519 --> 00:10:47,470 ‫an denselben oder einen sehr ähnlichen 238 00:10:47,470 --> 00:10:50,170 ‫Endpunkt geben, die das Löschen von Tour Nummer neun 239 00:10:50,170 --> 00:10:51,910 ‫von Benutzer Nummer drei anfordert, okay? 240 00:10:51,910 --> 00:10:54,440 ‫Es gibt also wirklich unzählige 241 00:10:54,440 --> 00:10:57,330 ‫Möglichkeiten, Ressourcen wie diese zu kombinieren. 242 00:10:57,330 --> 00:11:00,160 ‫Aber natürlich müssen wir nicht alle diese 243 00:11:00,160 --> 00:11:02,470 ‫Kombinationen in unserer API implementieren. 244 00:11:02,470 --> 00:11:04,260 ‫Wir implementieren nur das, 245 00:11:04,260 --> 00:11:06,600 ‫was für unsere Anwendung und den Client, der 246 00:11:06,600 --> 00:11:08,400 ‫unsere API nutzen möchte, sinnvoll ist. 247 00:11:08,400 --> 00:11:10,090 ‫So verwenden wir 248 00:11:10,090 --> 00:11:13,203 ‫HTTP-Methoden, um benutzerfreundliche und schön strukturierte URLs zu 249 00:11:13,203 --> 00:11:17,480 ‫erstellen, die für den Kunden einfach und logisch zu verwenden sind. 250 00:11:17,480 --> 00:11:20,823 ‫Nun zu den Daten, die der Client 251 00:11:20,823 --> 00:11:24,145 ‫tatsächlich empfängt oder die der Server 252 00:11:24,145 --> 00:11:27,800 ‫vom Client erhält, verwenden wir normalerweise das JSON-Datenformat. 253 00:11:27,800 --> 00:11:30,610 ‫Lassen Sie uns also kurz lernen, was JSON eigentlich 254 00:11:30,610 --> 00:11:33,203 ‫ist und wie wir unsere API-Antworten formatieren. 255 00:11:34,440 --> 00:11:37,400 ‫JSON ist ein sehr leichtes Datenaustauschformat, 256 00:11:37,400 --> 00:11:39,530 ‫das stark von 257 00:11:39,530 --> 00:11:43,780 ‫Web-APIs verwendet wird, die in jeder Programmiersprache codiert sind. 258 00:11:43,780 --> 00:11:46,220 ‫Es hat also nichts mit JavaScript zu tun. 259 00:11:46,220 --> 00:11:48,160 ‫Und es ist heute so weit verbreitet, weil 260 00:11:48,160 --> 00:11:50,740 ‫es sowohl für Menschen als auch für Computer sehr einfach ist, 261 00:11:50,740 --> 00:11:52,620 ‫JSON zu verstehen und zu schreiben. 262 00:11:52,620 --> 00:11:55,930 ‫Sie bemerken wahrscheinlich bereits, dass JSON ein bisschen wie 263 00:11:55,930 --> 00:11:57,990 ‫ein normales JavaScript-Objekt aussieht, oder? 264 00:11:57,990 --> 00:12:00,510 ‫Mit all diesen Schlüssel-Wert-Paaren. 265 00:12:00,510 --> 00:12:04,020 ‫Es gibt jedoch einige Unterschiede, und der 266 00:12:04,020 --> 00:12:06,470 ‫wichtigste ist, dass alle Tasten 267 00:12:06,470 --> 00:12:08,320 ‫Saiten sein müssen. 268 00:12:08,320 --> 00:12:10,960 ‫Es ist auch sehr typisch, dass die Werte ebenfalls Strings 269 00:12:10,960 --> 00:12:12,580 ‫sind, aber es können auch 270 00:12:12,580 --> 00:12:14,730 ‫andere Dinge wie Zahlen, wahre oder falsche 271 00:12:14,730 --> 00:12:17,440 ‫Werte, andere Objekte oder sogar Arrays mit anderen Werten sein. 272 00:12:17,440 --> 00:12:20,690 ‫Es ist eigentlich ganz einfach. 273 00:12:20,690 --> 00:12:23,328 ‫Und an diesem Beispiel können Sie sehen, 274 00:12:23,328 --> 00:12:25,790 ‫wie ein typisches JSON aussehen könnte. 275 00:12:25,790 --> 00:12:27,070 ‫Nehmen wir an, 276 00:12:27,070 --> 00:12:30,883 ‫dies sind Daten, die wir in unserer Datenbank für eine GET-Anfrage 277 00:12:31,890 --> 00:12:35,290 ‫an diese URL haben, damit die Tour mit I. D. von fünf. 278 00:12:35,290 --> 00:12:38,560 ‫Nun könnten wir es so an den Client zurücksenden, aber 279 00:12:38,560 --> 00:12:41,440 ‫normalerweise führen 280 00:12:41,440 --> 00:12:44,300 ‫wir vor dem Senden einige einfache Antwortformatierungen durch. 281 00:12:44,300 --> 00:12:47,130 ‫Dafür gibt es ein paar Standards und wir werden einen 282 00:12:47,130 --> 00:12:48,620 ‫sehr einfachen namens Jsend verwenden. 283 00:12:48,620 --> 00:12:50,880 ‫Wir erstellen einfach ein neues Objekt, 284 00:12:50,880 --> 00:12:54,570 ‫fügen ihm dann eine Statusmeldung hinzu, um den Client darüber 285 00:12:54,570 --> 00:12:56,320 ‫zu informieren, ob die 286 00:12:56,320 --> 00:12:58,310 ‫Anfrage erfolgreich, fehlgeschlagen oder fehlerhaft 287 00:12:58,310 --> 00:13:00,740 ‫war, und dann legen wir unsere Originaldaten 288 00:13:00,740 --> 00:13:03,350 ‫in ein neues Objekt namens Data, okay? 289 00:13:03,350 --> 00:13:05,390 ‫Und wir können das 290 00:13:05,390 --> 00:13:08,510 ‫noch ein bisschen weiterentwickeln, aber das ist wirklich die 291 00:13:08,510 --> 00:13:10,640 ‫einfachste Art der Formatierung mit Jsend. 292 00:13:10,640 --> 00:13:12,020 ‫Übrigens, das Einhüllen der Daten 293 00:13:12,020 --> 00:13:14,250 ‫in ein zusätzliches Objekt, wie wir es hier 294 00:13:14,250 --> 00:13:15,240 ‫getan haben, 295 00:13:15,240 --> 00:13:17,550 ‫wird Enveloping genannt, und es ist eine gängige 296 00:13:17,550 --> 00:13:19,860 ‫Praxis, einige Sicherheitsprobleme und andere Probleme zu mildern. 297 00:13:19,860 --> 00:13:21,470 ‫Es gibt auch 298 00:13:21,470 --> 00:13:25,550 ‫andere Standards für die Antwortformatierung, die Sie sich ansehen können, wie Jsend:API 299 00:13:25,550 --> 00:13:27,200 ‫oder das Odata JSON Protocol. 300 00:13:27,200 --> 00:13:30,330 ‫Okay, und schließlich 301 00:13:30,330 --> 00:13:34,333 ‫sollte eine RESTful-API immer zustandslos sein. 302 00:13:35,800 --> 00:13:37,470 ‫Was bedeutet eigentlich staatenlos? 303 00:13:37,470 --> 00:13:40,720 ‫Nun, in einer zustandslosen RESTful-API werden alle 304 00:13:40,720 --> 00:13:43,170 ‫Zustände auf dem Client 305 00:13:43,170 --> 00:13:45,960 ‫und nicht auf dem Server behandelt. 306 00:13:45,960 --> 00:13:48,410 ‫Und der Zustand bezieht sich einfach auf ein Datenelement in der Anwendung, 307 00:13:48,410 --> 00:13:50,120 ‫das sich im Laufe der Zeit ändern kann. 308 00:13:50,120 --> 00:13:52,910 ‫Zum Beispiel, ob ein bestimmter Benutzer eingeloggt ist 309 00:13:52,910 --> 00:13:55,750 ‫oder auf einer Seite mit einer Liste mit 310 00:13:55,750 --> 00:13:56,583 ‫mehreren 311 00:13:56,583 --> 00:13:58,720 ‫Seiten, was die aktuelle Seite ist. 312 00:13:58,720 --> 00:14:02,230 ‫Da der Status nun auf dem Client behandelt werden 313 00:14:02,230 --> 00:14:04,150 ‫soll, muss jede Anfrage 314 00:14:04,150 --> 00:14:06,170 ‫alle Informationen enthalten, die notwendig sind, 315 00:14:06,170 --> 00:14:09,910 ‫um eine bestimmte Anfrage auf dem Server zu bearbeiten, in Ordnung? 316 00:14:09,910 --> 00:14:12,710 ‫Ist das sinnvoll? 317 00:14:12,710 --> 00:14:15,780 ‫Der Server sollte sich also nie an 318 00:14:15,780 --> 00:14:17,170 ‫die vorherige 319 00:14:17,170 --> 00:14:21,030 ‫Anfrage erinnern müssen, um die aktuelle Anfrage zu verarbeiten. 320 00:14:21,030 --> 00:14:24,010 ‫Nehmen wir als Beispiel die Liste mit mehreren Seiten. 321 00:14:24,010 --> 00:14:25,906 ‫Und sagen wir das 322 00:14:25,906 --> 00:14:29,670 ‫wiederkehrend auf Seite fünf und wollen weiter zu Seite sechs. 323 00:14:29,670 --> 00:14:32,980 ‫Wir könnten also einen einfachen Endpunkt namens /tours/nextPage haben 324 00:14:32,980 --> 00:14:36,006 ‫und eine Anfrage an ihn senden, oder? 325 00:14:36,006 --> 00:14:39,710 ‫Aber der Server müsste dann herausfinden, was die aktuelle 326 00:14:40,650 --> 00:14:43,400 ‫Seite ist und basierend darauf die nächste 327 00:14:43,400 --> 00:14:45,610 ‫Seite an den Client senden. 328 00:14:45,610 --> 00:14:48,450 ‫Mit anderen Worten, der Server müsste sich 329 00:14:48,450 --> 00:14:50,496 ‫die vorherige Anfrage merken. 330 00:14:50,496 --> 00:14:51,730 ‫Es müsste 331 00:14:51,730 --> 00:14:54,950 ‫die State-Server-Seite behandeln und genau das wollen 332 00:14:54,950 --> 00:14:57,640 ‫wir bei RESTful-APIs vermeiden, okay? 333 00:14:57,640 --> 00:15:00,260 ‫Stattdessen sollten wir in diesem Fall 334 00:15:00,260 --> 00:15:03,120 ‫einen /tours/page-Endpunkt erstellen und die Nummer 335 00:15:03,120 --> 00:15:04,630 ‫sechs einfügen, 336 00:15:04,630 --> 00:15:07,550 ‫um die Seite Nummer sechs anzufordern. 337 00:15:07,550 --> 00:15:09,410 ‫Auf diese Weise würden wir dann 338 00:15:09,410 --> 00:15:11,850 ‫auf dem Client angeben, weil wir bei einem 339 00:15:11,850 --> 00:15:14,340 ‫Client bereits wissen, dass wir auf Seite fünf sind, 340 00:15:14,340 --> 00:15:15,410 ‫und wir müssen 341 00:15:15,410 --> 00:15:18,320 ‫nur noch eine hinzufügen und dann Seite Nummer sechs anfordern. 342 00:15:18,320 --> 00:15:20,750 ‫Der Server muss sich in diesem 343 00:15:20,750 --> 00:15:22,750 ‫Fall also nichts merken. 344 00:15:22,750 --> 00:15:23,920 ‫Alles, was es tun muss, ist, 345 00:15:23,920 --> 00:15:25,840 ‫die Daten für Seite Nummer sechs wie von uns angefordert zurückzusenden. 346 00:15:25,840 --> 00:15:27,940 ‫Und ganz nebenbei sind 347 00:15:27,940 --> 00:15:30,840 ‫Zustandslosigkeit und Staatlichkeit, das Gegenteil, sehr 348 00:15:30,840 --> 00:15:33,891 ‫wichtige Begriffe in der Informatik und im 349 00:15:33,891 --> 00:15:35,760 ‫Anwendungsdesign im Allgemeinen. 350 00:15:35,760 --> 00:15:38,560 ‫Daher ist es eine gute Idee, tatsächlich zu verstehen, was 351 00:15:38,560 --> 00:15:40,800 ‫eine zustandslose API ist und wie sie funktioniert. 352 00:15:40,800 --> 00:15:44,070 ‫Das war jedenfalls ein riesiger Vortrag, 353 00:15:44,070 --> 00:15:47,331 ‫aber auch einer der wichtigsten. 354 00:15:47,331 --> 00:15:50,280 ‫Ich kann das nicht oft genug betonen und ich denke 355 00:15:50,280 --> 00:15:52,670 ‫eigentlich, dass man das sehen kann, oder? 356 00:15:52,670 --> 00:15:55,700 ‫Wie auch immer, kommen wir nun endlich zurück zu unserem Code.