Das erste Modul endete damit, dass Sie eine HTTP-Anfrage erstellten, diese abschickten und eine Antwort erhielten.

Dies werden wir in Zukunft noch viele Male tun. Wir werden Anfragen an Server von Drittanbietern senden. Wir werden Anwendungen erstellen, die selbst solche Anfragen annehmen und eine Antwort zurücksenden. Wir werden eine komplexe Logik für die Verarbeitung von Anfragen entwickeln.

Daher wäre es gut, alles, was mit diesen Anfragen zu tun hat, gründlich zu studieren und im Detail zu analysieren. Damit Sie die Anfrage nicht einfach irgendwo abschreiben und wiederholen können, sondern wirklich herausfinden, wie das Ganze funktioniert.

Genau das werden wir im zweiten Modul tun. Los geht's!

Beginnen wir mit der Theorie.


REST API lernen

REST-API-Grundlagen

Wenn Sie Ihre Hausaufgaben im ersten Modul gemacht und die Dokumentation studiert haben, dürfte Ihnen das Akronym API aufgefallen sein. Tatsächlich ist es die API-Dokumentation, die Entwickler als erstes studieren sollten, wenn sie die Interaktion mit einem Dienst oder einer Anwendung im Netz verstehen wollen.

API - Anwendungsprogrammierschnittstelle. Dies ist eine Beschreibung der Art und Weise, wie der Client und der Server miteinander kommunizieren können. Wir öffnen die API-Dokumentation und erfahren dort, wie wir die erforderlichen Daten vom Server erhalten.

Wir wollen immer, dass diese Interaktion einfach und verständlich ist. Das vereinfacht die Aufgabe sowohl für die Entwickler (man muss das Rad nicht neu erfinden, wenn man einen neuen Dienst entwirft) als auch für die Benutzer (ein Dienst ist viel leichter zu erlernen, wenn er nach dem gleichen Prinzip funktioniert wie bereits bekannte Dienste). Und hier lohnt es sich, an einen neuen Begriff zu erinnern - REST.

REST - Akronym für Representational State Transfer. Es mag nicht sehr klar klingen, aber einfach ausgedrückt, ist REST ein Stil der Interaktion (Informationsaustausch) zwischen einem Client und einem Server.

Dabei handelt es sich nicht um einen starren Satz von Regeln und Anforderungen. REST erzwingt weder die Verwendung einer bestimmten Programmiersprache noch bindet es die Hände an strenge Richtlinien. REST wird als Architekturstil bezeichnet und definiert 6 Grundsätze, denen eine Systemarchitektur entsprechen muss.

Dementsprechend wird eine API, die unter Berücksichtigung der REST-Grundsätze entwickelt wurde, als REST-API bezeichnet, und die Anwendungen selbst werden als RESTful

Da wir genau solche RESTful-Anwendungen erstellen werden, lohnt es sich, gleich auf die Grundsätze einzugehen, denen sie entsprechen werden.

  1. Client-Server-Modell. Das Prinzip definiert die Trennung von Client und Server, die Differenzierung ihrer Bedürfnisse. Der Client muss sich nicht darum kümmern, wie die Daten gespeichert werden, die Hauptsache ist, dass sie auf Anforderung ausgegeben werden. Dem Server wiederum ist es egal, was der Client mit diesen Daten macht, wie er sie weiterverarbeitet und anzeigt. So können sie sich unabhängig voneinander entwickeln, und die Skalierbarkeit des Systems wird verbessert.
  2. Zustandslosigkeit. Dieses Prinzip bedeutet, dass der Server die Antwort nicht auf der Grundlage früherer Erfahrungen mit diesem Client "ausdenken" sollte. Jede Anfrage wird so gestellt, dass sie alle notwendigen Informationen für ihre Bearbeitung enthält, unabhängig von früheren Anfragen.
  3. Caching. Um die übertragenen Daten zu minimieren, gibt es einen Caching-Mechanismus. Wenn zum Beispiel ein Logo auf einer Seite angezeigt wird, ist es nicht sinnvoll, es jedes Mal vom Server anzufordern. Da es sich nicht so oft ändert, reicht es aus, es einmal abzurufen und auf dem Computer des Clients im Cache zu speichern. Aber wenn wir Informationen über die aktuelle Geschwindigkeit des Autos benötigen, dann hilft der Cache in keiner Weise weiter. Dieses Prinzip legt fest, dass die vom Server übermittelten Daten als cachefähig oder nicht cachefähig bezeichnet werden sollten.
  4. Einheitliche Schnittstelle. Dieser Grundsatz legt ein einheitliches Format für die Interaktion zwischen Client und Server fest. Die Struktur aller Anfragen muss die gleiche sein. Die Daten müssen in der gleichen Form gesendet werden, unabhängig davon, wer sie anfordert.
  5. Mehrschichtiges System. Der Client und der Server kommunizieren nicht unbedingt direkt miteinander. Die Datenübertragung kann über mehrere Zwischenknoten laufen. In diesem Fall ist das System so konzipiert, dass weder der Client noch der Server wissen, ob sie mit der endgültigen Anwendung oder einem Zwischenknoten interagieren. Auf diese Weise lässt sich die Last auf den Servern ausgleichen und die Skalierbarkeit erhöhen.
  6. Code auf Anfrage (optional). Der einzige Grundsatz, der nicht obligatorisch ist. Demnach kann der Client seine Funktionalität erweitern, indem er ausführbaren Code vom Server herunterlädt (z. B. Skripte). In diesem Fall sollte der Code nur bei Bedarf ausgeführt werden.

Nicht zu viel Theorie?

Lassen Sie uns das in die Praxis umsetzen.

Erstellen einer API-Anfrage

Öffnen wir AppMaster, erstellen wir eine API-Anfrage und erfahren wir, wie diese Anfrage funktioniert.


API-Anforderungen werden im Abschnitt "Geschäftslogik" auf der Registerkarte "Externe API-Anforderungen" erstellt.

Klicken Sie nun auf "+ Neue API-Anfrage".


Der Name und die Beschreibung können beliebig gewählt werden, sie sind nur für den persönlichen Gebrauch bestimmt.

Kommen wir zu den Daten, die wirklich wichtig sind.

Das Mindeste, was zum Erstellen einer Anfrage erforderlich ist, ist die Angabe der Methode und der Adresse (URL). Beginnen wir mit dem letzten Punkt.


URL - Uniform Resource Locator. Eine Adresse, die einer bestimmten Ressource im Internet zugeordnet ist. Die bekannteste Version einer solchen Ressource ist eine HTML-Seite - wir geben ihre URL in die Adressleiste des Browsers ein und öffnen die gewünschte Seite. Dabei kann die Ressource selbst alles Mögliche sein, ein Bild, ein Video, ein Datensatz. Die Hauptsache ist, dass diese Ressource einen spezifischen Zeiger hat - eine URL, an die Sie eine Anfrage senden können, um diese Ressource zu erhalten.

Indem wir uns auf die Daten an ihrer Adresse beziehen, geben wir auch die Methode (man kann auch sagen, den Typ) der Anfrage an, d. h. wir geben an, was mit diesen Daten tatsächlich getan werden muss.

Als wir Anfragen für die Aufgabe des ersten Moduls gesendet haben, haben wir Daten erhalten. Dies ist die GET-Methode. Diese Methode ist die naheliegendste und auch die einzige erforderliche Methode. Auch wenn wir sie nicht explizit angegeben haben, wurde daher standardmäßig angenommen, dass es sich um GET handelt.

Schauen wir uns an, welche anderen Methoden es gibt.


Der HTTP-Standard selbst schränkt die Anzahl der Methoden, die verwendet werden können, nicht ein. Gleichzeitig werden nur noch einige der gängigsten Methoden verwendet, um die Kompatibilität zu wahren. Es gibt 5 verschiedene Methoden, die in den AppMaster API-Anfragen verwendet werden können.

  • GET. Das ist bereits erledigt. Die Methode fordert die Bereitstellung einer Ressource an und empfängt Daten.
  • POST. Um Daten von irgendwoher zu erhalten, müssen Sie diese Daten zunächst dort ablegen. Die POST-Methode macht genau das. Sie sendet Daten an den Server und erstellt eine Ressource.
  • PUT. Ähnlich wie die POST-Methode, aber ihre Aufgabe ist es, die Daten zu aktualisieren. Es werden keine neuen Daten erstellt, sondern bestehende Daten ersetzt und aktualisiert.
  • DELETE. Wie der Name schon sagt, werden damit Daten gelöscht.
  • PATCH. Diese Methode ähnelt der Methode PUT, wird aber verwendet, um die Daten teilweise zu aktualisieren, anstatt sie vollständig zu ersetzen. Mit der PATCH-Methode können Sie zum Beispiel den Titel eines Artikels oder den Wert eines Parameters ändern.

Dabei ist es wichtig zu beachten, dass der Server nicht genau das tun muss, was in der Methode angegeben ist. Wir können die Adresse einer Seite mit der DELETE-Methode senden, aber das bedeutet nicht, dass der Server sie auch tatsächlich löscht. Aber rein theoretisch kann er dies auch mit dem GET-Befehl tun. Oder nichts ändern, aber gleichzeitig Daten als Antwort auf POST senden. Einfach weil der Entwickler es so konfiguriert hat.

Hier kommt REST ins Spiel, das besagt, dass es an der Zeit ist, sich auf die Einhaltung des Auftrags zu einigen, das Durcheinander zu beenden und genau das zu tun, was in der Methode angegeben ist. Zumindest sollte dies die Hauptaufgabe sein (wenn auch nicht unbedingt die einzige). Wenn Sie z. B. den Inhalt eines Artikels mit der GET-Methode übertragen, können Sie gleichzeitig den Zähler der Anzahl seiner Aufrufe um 1 erhöhen.

Wir haben also herausgefunden, wo sich die Daten befinden und was man mit ihnen machen kann. Gehen wir weiter und sehen wir uns an, welche anderen Komponenten die Anfrage haben kann.


URL-Parameter. Es gibt Situationen, in denen wir nur einen Teil der URL kennen. Ein Beispiel sind die Artikel auf der Website Appmaster.io. Die Startadresse für alle Artikel ist die gleiche - https://appmaster.io/en/blog/. Aber dann hat jeder Artikel seinen eigenen Titel und dementsprechend seinen eigenen individuellen Teil für die genaue Angabe dieses speziellen Artikels.

In einer solchen Situation werden URL-Params verwendet. Wir geben den allgemeinen Teil sofort vor und überlassen den Rest dem Prozess. Im Ergebnis wird die URL in der Form https://appmaster.io/ru/blog/:id/ geschrieben.

Der bekannte Teil wird so geschrieben, wie er ist, und der variable Teil wird hinter das ":"-Zeichen gesetzt. Der Name dieses variablen Teils (bereits ohne ":") wird in die Liste der Parameter aufgenommen. In diesem Fall kann es mehrere variable Teile geben, die an beliebiger Stelle in der URL stehen können.


Abfrage-Parameter. Erinnern Sie sich daran, dass wir im ersten Modul eine Anfrage an boredapi.com geschickt haben? Und neben der Adresse wurden zusätzliche Daten vorgeschrieben. Das waren die Query Params.

Sie werden nach der URL geschrieben und sind durch ein "?"-Zeichen von ihr getrennt. Angegeben werden der Name des Parameters, das Zeichen "=" und der Wert des Parameters selbst. Wenn mehrere Parameter auf einmal verwendet werden, werden sie durch das Zeichen "&" getrennt.

Bei der Angabe von Parametern in AppMaster müssen Sie sich jedoch keine Gedanken über die Abfrageregeln machen. Alles wird automatisch richtig formatiert. Sie müssen nur den Namen des Parameters selbst angeben und ihn der Liste hinzufügen.

Query Params werden verwendet, wenn die Datenquelle dieselbe ist, aber die Daten selbst unterschiedlich sein können. Zum Beispiel enthielt Boredapi eine riesige Liste von Dingen, die zu tun waren. Wir waren aber nur an denjenigen interessiert, die für eine Person bestimmt waren, und das haben wir in den Abfrageparametern angegeben.

Eine weitere Option ist ein Zugriffsschlüssel. Sie haben diese Option vielleicht schon in Modul 1 verwendet, als es um Alphavantage ging. Die Daten konnten nur nach Registrierung und Übermittlung eines persönlichen Schlüssels in den Anfrageparametern abgerufen werden.

Achten Sie auf die Seiten, die Sie im Internet besuchen, Sie werden wahrscheinlich auch dort verschiedene Parameter finden. Wenn Sie zum Beispiel die Wetterseite von Ventusky.com öffnen, werden in den Abfrageparametern die geografischen Werte von Breiten- und Längengrad gesendet.

Kopfzeilen. Anfrage-Header. Header enthalten in der Regel Service-Informationen über die Anfrage (Meta-Informationen). Header ermöglichen es dem Server, weitere Informationen über den Client zu erhalten, der die Daten anfordert. Die Header können Informationen darüber enthalten, welcher Browser verwendet wird, in welcher Kodierung die Antwort erwartet wird, in welcher Sprache, den genauen Zeitpunkt der Anfrage und vieles mehr. Im Falle des Zugriffs auf geschützte Daten können die Header einen Autorisierungsschlüssel enthalten.

In den meisten Fällen sind die Header optional. Bereits im ersten Modul haben wir eine Anfrage gestellt, bei der wir keine Header angegeben haben (was allerdings nicht bedeutet, dass die Anfrage tatsächlich ohne sie gesendet wurde).

Körper. Der Körper der Anfrage. GET-Anfragen kommen in der Regel ohne ihn aus, aber wenn wir einige Daten an den Server senden wollen, also eine POST- oder PUT-Anfrage stellen, dann werden diese Daten im Body der Anfrage untergebracht. Gleichzeitig können Sie Daten beliebiger Komplexität in den Request Body einfügen, z. B. eine Videodatei, und sind nicht auf eine Zahl oder eine Textzeichenfolge beschränkt.

Die Antwort, die vom Server kommt, funktioniert fast nach dem gleichen Schema. Sie hat aus offensichtlichen Gründen keine Anforderungsparameter, aber die Header und der Body sind in der Antwort enthalten (obwohl sie leer sein können).

Ein wichtiger Unterschied ist der Status der Antwort.

DerStatuscode. Er steht in der ersten Zeile der Serverantwort. Der Status ist eine dreistellige Zahl (der Code selbst), gefolgt von einem erklärenden Satz.

Anhand des Statuscodes können Sie sich über die Ergebnisse der Anfrage informieren und erfahren, welche Maßnahmen als Nächstes ergriffen werden sollten.

Alle möglichen Statuscodes sind in 5 Klassen unterteilt. Die erste Ziffer des Codes bestimmt die Zugehörigkeit zu einer bestimmten Klasse. Schauen wir uns die einzelnen Klassen an.

1xx - Informationscodes. Sie geben Auskunft über den Fortschritt der Anfrage. In der Praxis werden sie nur selten verwendet.

2xx - Erfolgscodes. Sie melden, dass alles in Ordnung ist und die Anfrage erfolgreich abgeschlossen wurde. Als Antwort auf eine GET-Anfrage erwarten wir normalerweise einen 200 (OK)-Code. Eine erfolgreiche PUT-Anfrage sendet einen 201 (Created)-Code.

3xx - Weiterleitungen. Zeigen an, dass die Anfrage an eine andere Adresse gesendet werden sollte. Ein Beispiel ist der Code 301 (Moved Permanently), der anzeigt, dass sich die gewünschten Daten nun an einer neuen Adresse befinden (die neue Adresse selbst wird im Location-Header übergeben).

4xx - Client-Fehlercodes. Der bekannteste von ihnen - 404 (Not Found) - meldet, dass es an der angegebenen Adresse keine erforderlichen Daten gibt. Andere häufige Fälle: 400 (Bad Request, Syntaxfehler in der Anfrage), 401 (Unauthorized, Authentifizierung für den Zugriff erforderlich), 403 (Forbidden, Zugriff verweigert).

5xx - Server-Fehlercodes. Melden einen Fehler auf der Serverseite. Als Beispiel: 500 (Internal Server Error, ein unverständlicher Fehler, der nicht auf einen bekannten Code zurückgeführt werden kann), 503 (Service Unavailable, der Server ist aus technischen Gründen vorübergehend nicht in der Lage, die Anfrage zu bearbeiten)

An dieser Stelle können wir davon ausgehen, dass wir die grundlegenden Informationen zum Verständnis der REST-API und der Struktur von HTTP-Anfragen und -Antworten behandelt haben. Es bleibt nur noch ein Punkt zu klären - die Datentypen. Wenn Sie bereits versucht haben, Ihre API-Anfrage in AppMaster zu erstellen, ist Ihnen wahrscheinlich aufgefallen, dass Sie bei allen Daten (in Parametern, in Headern, im Body) nicht nur den Namen, sondern auch den Datentyp angeben müssen.


Für einen Menschen ist es in der Regel ziemlich offensichtlich, wie mit den Daten zu arbeiten ist, da es einen bestimmten Kontext gibt. Angenommen, wir wissen, dass 2 + 2 = 4 ist. Wir vermuten, dass es sich dabei um Zahlen handelt und das Ergebnis der Addition eine weitere Zahl sein wird.

Aber vielleicht sind es keine Zahlen, sondern Textdaten. Dann könnte das Ergebnis ihrer Addition die Verkettung von Zeichenketten sein und 2 + 2 würde zu "22" werden. Damit der Computer sich nichts einfallen lassen muss, gibt es hier eine genaue Angabe des Datentyps. Und gleichzeitig werden auch andere Aufgaben gelöst. So wird zum Beispiel ein Schutz vor der Eingabe falscher Daten geboten; in dem Feld, das für die Eingabe von Telefonnummern vorgesehen ist, gibt es zunächst keine Möglichkeit, eine E-Mail-Adresse einzutragen.

Es gibt eine ganze Reihe verschiedener Datentypen, wir werden jetzt die grundlegendsten betrachten und uns in weiteren Modulen des Kurses mit den übrigen vertraut machen.

String - String-Datentyp, einfacher Text ohne spezielle Formatierung.

Integer - Ganzzahliger Datentyp. Kann für Zähler oder Berechnungen verwendet werden, bei denen keine Bruchzahlen benötigt werden.

Float - Fließkommazahl. Wird verwendet, wenn eine höhere Genauigkeit erforderlich ist und ganzzahlige Werte nicht ausreichen.

Hier könnte eine logische Frage auftauchen. Und warum nicht immer Float, warum brauchen wir dann Integer? Aber eine höhere Genauigkeit erfordert mehr Ressourcen. Für einige kleine Berechnungen mag dies völlig unsichtbar sein, aber bei großen Datenmengen kann die Verwendung eines vernünftigen Datentyps die Anforderungen an Rechenleistung und Speicherplatz erheblich reduzieren.

Boolean - boolescher Datentyp. Der einfachste Datentyp. Er nimmt einen von zwei Werten an, die als True oder False geschrieben werden. Man sieht die Bezeichnung oft in Form von 1 (wahr) und 0 (falsch).


Hausaufgabe

Wiederholen Sie die Anforderungen aus der Hausaufgabe zum ersten Modul, indem Sie sie in AppMaster im Abschnitt Externe API-Anforderungen erstellen.

  1. Erstellen Sie eine Anfrage an BoredAPI. Geben Sie mindestens 5 verschiedene Parameter aus der Dokumentation an. Senden Sie mehrere verschiedene Anfragen, wobei Sie nur die erforderlichen Parameter angeben.
  2. Erstellen Sie eine Anfrage an Alphavantage. Verwenden Sie die Parameter, um die Kurse verschiedener Währungen im Verhältnis zueinander zu ermitteln.