REST-API-Theorie

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 hin kopieren und wiederholen können, sondern wirklich herausfinden, wie das Ganze funktioniert.

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

Allgemeine Theorie

Fangen wir mit der Theorie an.

Wenn Sie Ihre Hausaufgaben im ersten Modul gemacht und die Dokumentation studiert haben, sollte 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

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

REST - Akronym für Representational State Transfer. Es mag nicht sehr klar klingen, aber einfach ausgedrückt ist REST eine Art der Interaktion (Austausch von Informationen) 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.

RESTful-Grundsätze

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.

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.

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.

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.

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 können Sie die Last auf den Servern ausgleichen und die Skalierbarkeit erhöhen.

Code auf Anfrage (optional). Das einzige Prinzip, das 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.