‫Kursleiter: Jetzt, da wir wissen, was Express ist, sind
‫wir fast so weit, mit der Erstellung unserer API zu beginnen.
‫Aber bevor wir
‫das tun, muss ich kurz über APIs auf einer höheren
‫Ebene sprechen und, was
‫noch wichtiger ist, Ihnen die REST-Architektur
‫vorstellen, die heute die am häufigsten verwendete API-Architektur ist.
‫Auf diese Weise wissen wir tatsächlich, was wir bauen.
‫Daher ist es äußerst wichtig, die Inhalte in
‫diesem Video zu verstehen, bevor wir
‫fortfahren, damit wir tatsächlich wissen, was wir im
‫weiteren Verlauf des Kurses aufbauen.
‫API steht
‫in erster Linie für Application Programming Interface und auf
‫sehr hohem Niveau ist
‫es im Grunde eine Software, die von einer
‫anderen Software verwendet werden kann,
‫um Anwendungen zu ermöglichen, miteinander zu kommunizieren.
‫Wir haben schon früher über
‫APIs gesprochen, genauer gesagt über Web-APIs, bei
‫denen wir einfach eine App erstellt haben,
‫die Daten an einen Client sendet, wenn eine Anfrage eingeht.
‫Stellen Sie sich vor, unsere App läuft auf einem Server
‫und wir haben einen Client.
‫Tatsächlich haben wir also effektiv zwei Softwarekomponenten, die
‫miteinander kommunizieren, oder?
‫Und das ist die Art von API, die wir in diesem Kurs erstellen werden.
‫Und ich denke, es ist die am weitesten verbreitete Art von API auf dem Markt.
‫Tatsächlich werden APIs jedoch nicht nur zum Senden von Daten verwendet und
‫haben nicht immer mit Webentwicklung oder JavaScript zu tun.
‫Die Anwendung in API kann tatsächlich
‫viele verschiedene Dinge bedeuten, solange die
‫Software relativ eigenständig ist.
‫Nehmen Sie
‫zum Beispiel das Node File System oder die HTTP-Module.
‫Wir können sagen, dass es sich um kleine Softwarestücke
‫handelt und wir
‫sie verwenden können, wir können mit ihnen über ihre API interagieren.
‫Wenn
‫wir beispielsweise die Readfile-Funktion des FS-Moduls verwenden,
‫verwenden wir tatsächlich die FS-API.
‫Deshalb hört man manchmal den Begriff Node-APIs.
‫Und das bezieht sich normalerweise einfach auf die Kernknotenmodule, mit
‫denen wir interagieren können.
‫Oder wenn wir die DOM-Manipulation im Browser
‫durchführen, verwenden wir nicht wirklich die JavaScript-Sprache selbst,
‫sondern die DOM-API, die der Browser uns zur Verfügung stellt, damit
‫wir darauf zugreifen können.
‫Oder noch ein anderes Beispiel,
‫sagen wir, wir erstellen eine Klasse in einer beliebigen Programmiersprache
‫wie Java und fügen ihr dann einige öffentliche Methoden
‫oder Eigenschaften hinzu.
‫Diese Methoden sind dann die API jedes aus
‫dieser Klasse erstellten Objekts, da wir
‫anderen Softwareteilen die Möglichkeit geben,
‫mit unserer ursprünglichen Software, in diesem Fall den
‫Objekten, zu interagieren.
‫Sie sehen, API hat tatsächlich eine breitere Bedeutung als
‫nur das Erstellen von Web-APIs.
‫In Ordung? Wie auch immer, eine Web-API ist
‫für uns im Kontext von Note am wichtigsten.
‫Werfen wir nun einen Blick auf die REST-Architektur, um
‫APIs zu erstellen.
‫REST, was für Representational States Transfer steht, ist im Grunde
‫eine Möglichkeit, Web-APIs auf logische Weise zu erstellen und sie
‫einfach zu nutzen, denn
‫denken Sie daran, dass wir eine API für
‫uns selbst oder für andere erstellen, okay?
‫Wir möchten den Prozess der tatsächlichen Nutzung der API für den
‫Benutzer so reibungslos wie möglich gestalten.
‫Um nun RESTful-APIs zu erstellen,
‫d. h. APIs, die der REST-Architektur folgen, müssen
‫wir nur ein paar Prinzipien befolgen.
‫Zuerst müssen wir unsere API in logische Ressourcen aufteilen.
‫Diese Ressourcen sollten dann
‫exponiert, das heißt
‫über strukturierte, ressourcenbasierte URLs verfügbar gemacht werden.
‫Um verschiedene Aktionen an Daten
‫durchzuführen, wie das Lesen oder Erstellen oder Löschen
‫von Daten, sollte die API die richtigen HTP-Methoden und nicht die URL verwenden.
‫Nun sollten die Daten, die wir tatsächlich an
‫den Client zurücksenden oder die
‫wir vom Client erhalten haben, normalerweise
‫das JSON-Datenformat verwenden, für das einige Formatierungsstandards gelten.
‫Schließlich ist ein weiteres wichtiges Prinzip von
‫REST-APIs, dass sie zustandslos sein müssen.
‫Dies ist also ein sehr breiter Überblick.
‫Lassen Sie uns nun nacheinander über
‫diese Prinzipien sprechen, beginnend mit den Ressourcen und der Verwendung
‫der Nators-API, die wir in diesem Kurs
‫als Beispiel hier erstellen werden.
‫Die wichtigste Abstraktion von Informationen in REST ist eine Ressource,
‫und daher sollten alle Daten,
‫die wir in der API teilen möchten, in logische Ressourcen unterteilt werden.
‫Was ist nun eigentlich eine Ressource?
‫Nun, im Kontext von
‫REST ist es ein Objekt oder eine Darstellung
‫von etwas, dem einige Daten zugeordnet sind.
‫Zum
‫Beispiel Touren oder Benutzer oder Bewertungen im
‫Fall des Beispiels, dem wir folgen.
‫Im Grunde können also alle Informationen, die benannt werden
‫können, eine Ressource sein, in Ordnung?
‫Es muss nur ein Name sein, kein Verb.
‫Jetzt müssen wir
‫die Daten mithilfe einiger strukturierter
‫URLs bereitstellen, d. h. verfügbar machen, an die
‫der Client eine Anfrage senden kann.
‫Zum Beispiel so etwas.
‫Diese gesamte Adresse wird als URL
‫bezeichnet und diese /addNewTour wird als API-Endpunkt bezeichnet.
‫Unsere API wird viele verschiedene Endpunkte haben,
‫genau wie diese fiktiven Endpunkte, die ich hier
‫habe, von denen jeder unterschiedliche Daten an den Client
‫zurücksendet oder auch unterschiedliche Aktionen ausführt.
‫Mit diesen Endpunkten stimmt hier
‫tatsächlich etwas sehr nicht, weil sie wirklich nicht
‫der dritten Regel folgen, die besagt, dass
‫wir die HTTP-Methoden nur verwenden sollten, um Aktionen mit Daten durchzuführen.
‫Endpunkte sollten also nur unsere Ressourcen enthalten und nicht
‫die Aktionen, die auf ihnen ausgeführt werden
‫können, da die Wartung schnell zu einem Albtraum wird.
‫Wie sollten wir diese HTTP-Methoden in der Praxis verwenden?
‫Sehen wir uns an,
‫wie diese Endpunkte tatsächlich aussehen sollten, beginnend mit /getTour.
‫Dieser Endpunkt /getTour dient also zum Abrufen von Daten zu einer Tour.
‫Also sollten wir einfach den Endpunkt /tours benennen und
‫die Daten senden, wenn eine Get-Anforderung an
‫diesen Endpunkt gestellt wird.
‫Mit anderen
‫Worten, wenn ein Client eine GET-HTTP-Methode verwendet,
‫um auf den Endpunkt zuzugreifen.
‫Und genau
‫so haben wir nur Ressourcen im
‫Endpunkt oder in der URL und keine Verben, weil
‫das Verb jetzt in der HTTP-Methode ist, richtig?
‫Übrigens
‫ist es üblich, den Ressourcennamen immer im
‫Plural zu verwenden, weshalb ich hier /tours und nicht /tour habe.
‫Nun, die Konvention ist, dass wir beim Aufrufen
‫dieses Endpunkts alle Touren zurückbekommen, die sich in einer Datenbank befinden, okay?
‫Aber wenn wir nur die Tour mit einem wollen, dann habe ich. D. sagen wir sieben, wir
‫fügen diese sieben nach einem weiteren Schrägstrich oder in einer Suchanfrage hinzu.
‫Oder es könnte statt des I auch der Name einer Tour sein. D. oder eine andere eindeutige Kennung.
‫Das Detail ist an dieser Stelle nicht wirklich wichtig, in Ordnung?
‫Später werde ich Ihnen zeigen,
‫wie einfach es ist, diese Art von Logik mit
‫Express tatsächlich umzusetzen, denn genau hier glänzt Express wirklich.
‫Die erste HTTP-Methode oder das
‫erste Verb, auf das wir antworten können, ist GET und
‫wird verwendet, um den Lesevorgang für Daten auszuführen.
‫Wenn der Kunde als nächstes
‫eine neue Ressource in unserer Datenbank erstellen möchte, in
‫diesem Beispiel eine
‫neue Tour, sollte die POST-Methode verwendet werden.
‫Wir haben also vorhin erfahren, dass eine
‫POST-Anfrage verwendet werden kann, um Daten an den Server
‫zu senden, und daher ist es sinnvoll, POST zu verwenden, um
‫neue Ressourcen zu erstellen, oder?
‫In diesem Fall normalerweise kein Ich. D. gesendet wird, da der Server
‫automatisch die I.
‫D. für die neue Ressource.
‫Auf jeden Fall ist es hier wirklich wichtig zu beachten, dass der Endpunktname genau derselbe
‫Name ist wie zuvor.
‫Der einzige Unterschied ist wirklich
‫die HTP-Methode, die für die Anfrage verwendet wird.
‫Wenn mit GET auf den Endpunkt /tours zugegriffen wird, senden
‫wir Daten an den Client.
‫Wenn jedoch mit POST auf denselben Endpunkt zugegriffen wird, erwarten
‫wir, dass Daten mit
‫einer Anfrage eingehen, damit wir dann auf
‫der Serverseite eine neue Ressource erstellen können.
‫Das ist also wirklich das Schöne daran, nur HTTP-Methoden zu
‫verwenden, anstatt mit Verben in Endpunktnamen herumzuspielen.
‫Auch hier würde es wirklich sehr schnell unüberschaubar werden.
‫In Ordnung, als nächstes sollte
‫es auch die Möglichkeit geben, Ressourcen zu aktualisieren.
‫Dazu sollte entweder eine PUT- oder
‫eine PATCH-Anfrage an den Endpunkt gestellt
‫werden.
‫Der Unterschied besteht darin, dass der
‫Client bei PUT das gesamte
‫aktualisierte Objekt senden soll, während bei
‫PATCH nur der Teil des Objekts gesendet werden soll, der
‫geändert wurde.
‫Beide haben jedoch die Möglichkeit, Daten an
‫den Server zu senden.
‫Eigentlich ein bisschen wie POST, aber mit einer anderen Absicht.
‫POST ist also das
‫Erstellen einer neuen Ressource, während PUT oder PATCH verwendet werden, um
‫eine vorhandene Ressource zu aktualisieren, und
‫so macht es dann den Unterschied.
‫Und schließlich gibt es
‫für die Abfallressource die HTTP-Methode DELETE.
‫Wieder das I. D. oder eine andere eindeutige Kennung der
‫zu löschenden Ressource sollte Teil der URL
‫sein.
‫Um diese Art von Anfrage
‫tatsächlich ausführen zu können,
‫muss der Client nun normalerweise authentifiziert werden.
‫Melden Sie sich also grundsätzlich bei Ihrer App an, okay?
‫Aber das ist natürlich ein Thema für viel später.
‫Dies sind also die fünf HTTP-Methoden, auf
‫die wir beim Erstellen unserer
‫RESTful-APIs reagieren können und sollten, damit
‫der Client die
‫vier grundlegenden CRUD-Operationen ausführen kann.
‫CRUD steht also für Create, Read, Update und Delete.
‫Und Sie werden diesen Begriff
‫ständig im Zusammenhang mit APIs und Datenbanken sehen.
‫Und Sie sehen, dass diese
‫HTTP-Methoden den grundlegenden CRUD-Operationen recht gut zugeordnet sind.
‫Nun, es könnte Aktionen geben,
‫die nicht CRUD sind, und in diesem Fall müssen
‫wir nur mit unseren Eingaben kreativ werden.
‫Zum Beispiel eine
‫Anmeldung oder ein Suchvorgang, diese beziehen sich nicht
‫wirklich
‫auf eine bestimmte Ressource und sind
‫auch keine CRUD-Vorgänge, aber wir können trotzdem Endpunkte dafür erstellen.
‫Zum Beispiel wie /login oder /search.
‫Aber wir werden später mehr über diese Fälle in der Praxis sprechen.
‫Und um diesen Teil jetzt abzuschließen, denken
‫Sie daran, dass wir auf der letzten Folie zwei
‫andere verrückte Endpunktnamen
‫hatten, die zwei Ressourcen gleichzeitig beinhalteten, richtig?
‫Und auch das ist mit REST kein Problem.
‫/getToursByUser kann also
‫einfach in /users/tours übersetzt werden,
‫in diesem Fall Benutzer Nummer drei.
‫Dieser spezielle Endpunkt hier könnte also Daten
‫über alle Touren senden, die Benutzer
‫Nummer drei gebucht hat.
‫Macht Sinn?
‫Oder im Falle des Löschens könnte es
‫eine Löschanforderung
‫an denselben oder einen sehr ähnlichen
‫Endpunkt geben, die das Löschen von Tour Nummer neun
‫von Benutzer Nummer drei anfordert, okay?
‫Es gibt also wirklich unzählige
‫Möglichkeiten, Ressourcen wie diese zu kombinieren.
‫Aber natürlich müssen wir nicht alle diese
‫Kombinationen in unserer API implementieren.
‫Wir implementieren nur das,
‫was für unsere Anwendung und den Client, der
‫unsere API nutzen möchte, sinnvoll ist.
‫So verwenden wir
‫HTTP-Methoden, um benutzerfreundliche und schön strukturierte URLs zu
‫erstellen, die für den Kunden einfach und logisch zu verwenden sind.
‫Nun zu den Daten, die der Client
‫tatsächlich empfängt oder die der Server
‫vom Client erhält, verwenden wir normalerweise das JSON-Datenformat.
‫Lassen Sie uns also kurz lernen, was JSON eigentlich
‫ist und wie wir unsere API-Antworten formatieren.
‫JSON ist ein sehr leichtes Datenaustauschformat,
‫das stark von
‫Web-APIs verwendet wird, die in jeder Programmiersprache codiert sind.
‫Es hat also nichts mit JavaScript zu tun.
‫Und es ist heute so weit verbreitet, weil
‫es sowohl für Menschen als auch für Computer sehr einfach ist,
‫JSON zu verstehen und zu schreiben.
‫Sie bemerken wahrscheinlich bereits, dass JSON ein bisschen wie
‫ein normales JavaScript-Objekt aussieht, oder?
‫Mit all diesen Schlüssel-Wert-Paaren.
‫Es gibt jedoch einige Unterschiede, und der
‫wichtigste ist, dass alle Tasten
‫Saiten sein müssen.
‫Es ist auch sehr typisch, dass die Werte ebenfalls Strings
‫sind, aber es können auch
‫andere Dinge wie Zahlen, wahre oder falsche
‫Werte, andere Objekte oder sogar Arrays mit anderen Werten sein.
‫Es ist eigentlich ganz einfach.
‫Und an diesem Beispiel können Sie sehen,
‫wie ein typisches JSON aussehen könnte.
‫Nehmen wir an,
‫dies sind Daten, die wir in unserer Datenbank für eine GET-Anfrage
‫an diese URL haben, damit die Tour mit I. D. von fünf.
‫Nun könnten wir es so an den Client zurücksenden, aber
‫normalerweise führen
‫wir vor dem Senden einige einfache Antwortformatierungen durch.
‫Dafür gibt es ein paar Standards und wir werden einen
‫sehr einfachen namens Jsend verwenden.
‫Wir erstellen einfach ein neues Objekt,
‫fügen ihm dann eine Statusmeldung hinzu, um den Client darüber
‫zu informieren, ob die
‫Anfrage erfolgreich, fehlgeschlagen oder fehlerhaft
‫war, und dann legen wir unsere Originaldaten
‫in ein neues Objekt namens Data, okay?
‫Und wir können das
‫noch ein bisschen weiterentwickeln, aber das ist wirklich die
‫einfachste Art der Formatierung mit Jsend.
‫Übrigens, das Einhüllen der Daten
‫in ein zusätzliches Objekt, wie wir es hier
‫getan haben,
‫wird Enveloping genannt, und es ist eine gängige
‫Praxis, einige Sicherheitsprobleme und andere Probleme zu mildern.
‫Es gibt auch
‫andere Standards für die Antwortformatierung, die Sie sich ansehen können, wie Jsend:API
‫oder das Odata JSON Protocol.
‫Okay, und schließlich
‫sollte eine RESTful-API immer zustandslos sein.
‫Was bedeutet eigentlich staatenlos?
‫Nun, in einer zustandslosen RESTful-API werden alle
‫Zustände auf dem Client
‫und nicht auf dem Server behandelt.
‫Und der Zustand bezieht sich einfach auf ein Datenelement in der Anwendung,
‫das sich im Laufe der Zeit ändern kann.
‫Zum Beispiel, ob ein bestimmter Benutzer eingeloggt ist
‫oder auf einer Seite mit einer Liste mit
‫mehreren
‫Seiten, was die aktuelle Seite ist.
‫Da der Status nun auf dem Client behandelt werden
‫soll, muss jede Anfrage
‫alle Informationen enthalten, die notwendig sind,
‫um eine bestimmte Anfrage auf dem Server zu bearbeiten, in Ordnung?
‫Ist das sinnvoll?
‫Der Server sollte sich also nie an
‫die vorherige
‫Anfrage erinnern müssen, um die aktuelle Anfrage zu verarbeiten.
‫Nehmen wir als Beispiel die Liste mit mehreren Seiten.
‫Und sagen wir das
‫wiederkehrend auf Seite fünf und wollen weiter zu Seite sechs.
‫Wir könnten also einen einfachen Endpunkt namens /tours/nextPage haben
‫und eine Anfrage an ihn senden, oder?
‫Aber der Server müsste dann herausfinden, was die aktuelle
‫Seite ist und basierend darauf die nächste
‫Seite an den Client senden.
‫Mit anderen Worten, der Server müsste sich
‫die vorherige Anfrage merken.
‫Es müsste
‫die State-Server-Seite behandeln und genau das wollen
‫wir bei RESTful-APIs vermeiden, okay?
‫Stattdessen sollten wir in diesem Fall
‫einen /tours/page-Endpunkt erstellen und die Nummer
‫sechs einfügen,
‫um die Seite Nummer sechs anzufordern.
‫Auf diese Weise würden wir dann
‫auf dem Client angeben, weil wir bei einem
‫Client bereits wissen, dass wir auf Seite fünf sind,
‫und wir müssen
‫nur noch eine hinzufügen und dann Seite Nummer sechs anfordern.
‫Der Server muss sich in diesem
‫Fall also nichts merken.
‫Alles, was es tun muss, ist,
‫die Daten für Seite Nummer sechs wie von uns angefordert zurückzusenden.
‫Und ganz nebenbei sind
‫Zustandslosigkeit und Staatlichkeit, das Gegenteil, sehr
‫wichtige Begriffe in der Informatik und im
‫Anwendungsdesign im Allgemeinen.
‫Daher ist es eine gute Idee, tatsächlich zu verstehen, was
‫eine zustandslose API ist und wie sie funktioniert.
‫Das war jedenfalls ein riesiger Vortrag,
‫aber auch einer der wichtigsten.
‫Ich kann das nicht oft genug betonen und ich denke
‫eigentlich, dass man das sehen kann, oder?
‫Wie auch immer, kommen wir nun endlich zurück zu unserem Code.