Übersicht über REST. Teil 2: Kommunikation zwischen Client und Server

Teil 1: Was ist REST? In diesem Teil werfen wir einen genaueren Blick darauf, wie die Kommunikation zwischen dem Client und dem Server abläuft. Unterwegs verraten wir Ihnen neue Begriffe und geben Erklärungen dazu. Um alles klar (zu) machen, analysieren wir die Client-Server-Kommunikation am Beispiel einer RESTful-Anwendung. Nehmen wir an, wir entwickeln eine Webanwendung, die Informationen über Kunden und deren Bestellungen speichern kann. Diese. Unser System ist in der Lage, einige Entitäten zu manipulieren: sie zu erstellen, zu bearbeiten, zu löschen und Informationen über sie bereitzustellen. Diese Einheiten werden sein:

• Kunden - Kunden;
• Bestellungen – Kundenbestellungen;
• Gegenstände - Waren.

In der REST-Architektur senden Clients Anfragen an den Server, um Daten abzurufen oder zu ändern, und Server senden Antworten an Clients auf ihre Anfragen.

Anfragen

Clientanfragen erfolgen fast immer über HTTP. Im Allgemeinen bestehen HTTP-Anfragen aus mehreren Komponenten:

• HTTP-Methode;
• Titel;
• URI;
• Anfragetext.

Im Folgenden werden wir uns die einzelnen Komponenten genauer ansehen.

URI und Ressourcen

Daten, die Clients durch Anfragen erhalten oder ändern, werden als Ressourcen bezeichnet. Die Grundlage der Client-Server-Interaktion ist die Manipulation von Ressourcen. Ressourcen in REST sind alles, was mit einem Namen versehen werden kann. In gewissem Sinne sind dies wie Klassen in Java. In Java können wir für alles eine Klasse erstellen. Dasselbe gilt auch für REST – eine Ressource kann alles sein: ein Benutzer, ein Dokument, ein Bericht, eine Bestellung. All dies kann entweder eine Abstraktion einer Entität oder etwas Konkretes sein, zum Beispiel eine Datei – ein Bild, ein Video, eine Animation, eine PDF-Datei. Für unser Beispiel haben wir 3 Ressourcen:

• Kunden - Kunden;
• Bestellungen – Kundenbestellungen;
• Gegenstände - Waren.

Clients senden Anfragen an sogenannte Endpunkte oder Endpunkte. Vereinfacht ausgedrückt ist ein Endpunkt so etwas wie eine Adresse im Netzwerk. Genauer gesagt ist ein Endpunkt ein URI : eine Zeichenfolge, die eine abstrakte oder physische Ressource identifiziert. Uniform Resource Identifier – ein einheitlicher Ressourcenbezeichner. Manchmal wird der Endpunkt oder URI als Pfad bezeichnet – der Pfad zu einer Ressource. Für die Zwecke dieses Artikels verwenden wir den Begriff URI. Jede spezifische Ressource muss einen eindeutigen URI haben. Die Verantwortung dafür, dass jede Ressource immer einen eigenen URI hat, liegt beim Serverentwickler. In unserem Beispiel sind wir die Entwickler, also werden wir es so machen, wie wir es können. So wie es in einer relationalen Datenbank oft üblich ist, den Primärschlüssel auf eine bestimmte numerische ID zu setzen, hat bei REST jede Ressource ihre eigene ID. Es kommt häufig vor, dass die ID einer Ressource in REST mit der ID des Datensatzes in der Datenbank übereinstimmt, in der Informationen zu dieser Ressource gespeichert sind. REST-URIs beginnen normalerweise mit der Pluralform eines Substantivs, das eine Ressource beschreibt. Zum Beispiel vom Wort Kunden. Als nächstes wird durch einen Schrägstrich eine ID angegeben – die Kennung eines bestimmten Kunden. Beispiele:

• /clients – URI aller vorhandenen Clients;
• /clients/23 – URI eines bestimmten Clients, nämlich des Clients mit der ID=23;
• /clients/4 – URI eines bestimmten Clients, nämlich des Clients mit der ID=4.

Aber das ist nicht alles. Wir können den URI erweitern, indem wir ihm Bestellungen hinzufügen:

• /clients/4/orders – URI aller Bestellungen von Kunde Nr. 4;
• /clients/1/orders/12 – URI der Bestellung Nr. 12 des Kunden Nr. 1.

Wenn wir diese Kette fortsetzen und Güter hinzufügen, erhalten wir:

• /clients/1/orders/12/items – URI der Liste aller Produkte in Bestellung Nr. 12, erstellt von Kunde Nr. 1.

Bei Verschachtelungsebenen liegt der Schlüssel darin, URIs intuitiv zu gestalten.

HTTP-Methode

HTTP-Methode (engl. HTTP Method) ist eine Folge beliebiger Zeichen, mit Ausnahme von Steuerelementen und Trennzeichen, die den Hauptvorgang an einer Ressource angibt. Es gibt mehrere gängige HTTP-Methoden. Wir listen diejenigen auf, die in RESTful-Diensten am häufigsten verwendet werden:

• GET – wird verwendet, um Informationen über eine bestimmte Ressource (über die ID) oder eine Sammlung von Ressourcen zu erhalten;
• POST – wird zum Erstellen einer neuen Ressource verwendet;
• PUT – wird verwendet, um eine Ressource zu ändern (über die ID);
• DELETE – wird zum Löschen einer Ressource (über die ID) verwendet.

Überschriften

Sowohl Anfragen als auch Antworten enthalten HTTP-Header. Sie senden zusätzliche Informationen zur Anfrage (oder Antwort). Header sind Schlüssel-Wert-Paare. Die Liste der häufigsten Überschriften können Sie auf der Wikipedia- Seite nachlesen . Mit REST können Clients in ihrer Anfrage häufig einen Accept-Header an den Server senden. Es ist erforderlich, dem Server mitzuteilen, in welchem ​​Format der Client eine Antwort von ihm erwartet. In der sogenannten MIME-Typenliste werden verschiedene Formatoptionen dargestellt. MIME (Multipurpose Internet Mail Extensions) ist eine Spezifikation zum Kodieren von Informationen und Formatieren von Nachrichten, damit sie über das Internet gesendet werden können. Jeder MIME-Typ besteht aus zwei Teilen, die durch einen Schrägstrich getrennt sind: einem Typ und einem Subtyp. Beispiele für MIME-Typen für verschiedene Dateitypen:

• text – text/plain, text/css, text/html;
• Bild – Bild/PNG, Bild/JPEG, Bild/GIF;
• Audio – Audio/WAV, Audio/MPEG;
• Video – Video/mp4, Video/ogg;
• Anwendung – Anwendung/json, Anwendung/pdf, Anwendung/xml, Anwendung/Oktett-Stream.

Insgesamt kann die Anfrage den folgenden Header haben:

Accept:application/json

Dieser Header teilt dem Server mit, dass der Client eine Antwort im JSON-Format erwartet.

Anforderungstext

Eine vom Client an den Server gesendete Nachricht. Ob eine Anfrage einen Textkörper hat oder nicht, hängt von der Art der HTTP-Anfrage ab. Beispielsweise enthalten GET- und DELETE-Anfragen normalerweise keinen Anfragetext. Aber PUT und POST können enthalten: Es geht um den funktionalen Zweck des Anfragetyps. Denn um Daten zu empfangen und per ID (die in der URL übertragen wird) zu löschen, müssen Sie keine zusätzlichen Daten an den Server senden. Um jedoch eine neue Ressource zu erstellen (POST-Anfrage), müssen Sie diese Ressource übertragen. Das Gleiche gilt für die Änderung einer vorhandenen Ressource. In REST werden am häufigsten XML- oder JSON-Formate zur Übertragung des Anforderungstexts verwendet. Das gebräuchlichste Format ist JSON. Angenommen, wir möchten eine Anfrage an den Server senden und darin eine neue Ressource erstellen. Wenn Sie sich erinnern, haben wir uns als Beispiel eine Anwendung angesehen, die Kundenbestellungen verwaltet. Nehmen wir an, wir möchten einen neuen Kunden erstellen. In unserem Fall speichern wir die folgenden Informationen über Kunden: Name E-Mail Telefonnummer Dann könnte der Text einer solchen Anfrage der folgende JSON sein:

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+7 (191) 746-43-23"
}

Anfragen zusammenstellen

Deshalb haben wir uns angeschaut, woraus eine Kundenanfrage bestehen kann. Lassen Sie uns nun einige Beispiele für Abfragen mit Beschreibungen geben

Antworten

Lassen Sie uns ein paar Worte zu den Antworten des Servers sagen. Die Antwort besteht in der Regel aus folgenden Teilen:

• Antwortcode;
• Kopfzeilen;
• Antwortkörper.

Im Allgemeinen unterscheiden sich Antwortheader nicht wesentlich von Anforderungsheadern. Darüber hinaus werden einige Header sowohl in Antworten als auch in Anfragen verwendet. Ich denke, auch mit dem Text der Antwort ist alles klar. Der Körper gibt häufig Informationen zurück, die der Kunde angefordert hat. Informationen können im gleichen JSON-Format für GET-Anfragen zurückgegeben werden. Aber der letzte Teil ist etwas interessanter.

HTTP-Antwortcodes

Schauen wir uns die HTTP-Antwortcodes genauer an. Hier ein Zitat aus Wikipedia: Der HTTP-Statuscode ist Teil der ersten Zeile der Serverantwort für Anfragen über das HTTP-Protokoll. Es ist eine ganze Zahl mit drei Dezimalstellen. Die erste Ziffer gibt die Klasse der Bedingung an. Auf den Antwortcode folgt normalerweise ein erklärender Satz in englischer Sprache, getrennt durch ein Leerzeichen, der der Person den Grund für diese bestimmte Antwort erklärt. Beispiele:

• 201 erstellt;
• 401 nicht Autorisiert;
• 507 Nicht genügend Speicherplatz.

Der Client erfährt aus dem Antwortcode die Ergebnisse seiner Anfrage und bestimmt, welche Maßnahmen er als nächstes ergreifen soll. Antwortcodes sind in mehrere Gruppen unterteilt:

• 1ХХ - informativ;
• 2ХХ – über Fälle der erfolgreichen Annahme und Bearbeitung der Kundenanfrage informieren;
• 3XX – Informieren Sie den Client darüber, dass für den erfolgreichen Abschluss des Vorgangs eine weitere Anfrage erforderlich ist, normalerweise unter Verwendung eines anderen URI.
• 4ХХ – Clientfehler. Zum Beispiel eine falsch konstruierte Anfrage oder der bekannte Code 404 Not Found, der auftreten kann, wenn ein Client eine nicht vorhandene Ressource anfordert;
• 5ХХ - Serverfehler. Wird an den Client zurückgegeben, wenn der Vorgang aufgrund eines Fehlers des Servers fehlschlägt.

Weitere Informationen zu allen Codes finden Sie hier . Teil 1: Was ist REST? Teil 3: Erstellen eines RESTful-Dienstes in Spring Boot