Übersicht über REST. Teil 1: Was ist REST? In diesem Teil werden wir uns eingehend damit befassen, wie die Kommunikation zwischen einem Client und einem Server stattfindet. Ganz nebenbei entdecken wir neue Begriffe und erklären diese. Damit alles klar ist, analysieren wir die Client-Server-Kommunikation am Beispiel einer RESTful-Anwendung. Angenommen, wir entwickeln eine Webanwendung, die Informationen über Kunden und ihre Bestellungen speichert. Mit anderen Worten: Unser System ist in der Lage, Operationen an bestimmten Entitäten durchzuführen: sie zu erstellen, zu bearbeiten und zu löschen und Informationen über sie anzuzeigen. Diese Einheiten werden sein:
Kunden (Kunden)
Bestellungen (Kundenbestellungen)
Artikel (Produkte)
In einer RESTful-Architektur senden Clients Anfragen an einen Server, um Daten abzurufen oder zu ändern, und dann senden Server den Clients Antworten auf ihre Anfragen.
Anfragen
Clientanfragen werden fast immer über das HTTP-Protokoll gestellt. Im Allgemeinen bestehen HTTP-Anfragen aus mehreren Komponenten:
HTTP-Methode
Header
URI
Anfragetext
Im Folgenden werden wir jede Komponente detaillierter betrachten.
URIs und Ressourcen
Die Daten, die Clients durch Anfragen erhalten oder ändern, werden als Ressourcen bezeichnet. Bei der Client-Server-Kommunikation geht es vor allem um die Manipulation von Ressourcen. In REST sind Ressourcen alles, was Sie benennen können. In gewissem Sinne sind sie wie Klassen in Java. In Java können wir für alles eine Klasse erstellen. In REST kann eine Ressource also alles sein: ein Benutzer, ein Dokument, ein Bericht, eine Bestellung. Dabei kann es sich entweder um eine Abstraktion einer Entität oder um etwas Bestimmtes handeln, beispielsweise um ein Bild, ein Video, eine Animation oder eine PDF-Datei. In unserem Beispiel haben wir 3 Ressourcen:
Kunden (Kunden)
Bestellungen (Kundenbestellungen)
Artikel (Produkte)
Clients senden Anfragen an Ressourcenstandorte, die als Endpunkte bezeichnet werden. Vereinfacht gesagt ist ein Endpunkt wie eine Adresse im Netzwerk. Wenn wir tiefer gehen, können wir sagen, dass ein Endpunkt ein URI ist, also eine Zeichenfolge, die eine abstrakte oder physische Ressource identifiziert. Uniform Resource Identifier (URI) Manchmal wird ein Endpunkt oder URI als Pfad bezeichnet, also als Pfad zu einer Ressource. Für die Zwecke dieses Artikels verwenden wir den Begriff URI. Jede spezifische Ressource muss einen eindeutigen URI haben. Der Serverentwickler ist dafür verantwortlich, sicherzustellen, dass jede Ressource immer einen eigenen URI hat. 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, numerische Bezeichner als Primärschlüssel zu vergeben, hat auch in REST jede Ressource eine eigene ID. Die Ressourcen-ID in REST stimmt häufig mit der ID des Datensatzes in der Datenbank überein, in dem Informationen über die Ressource gespeichert sind. REST-URIs beginnen üblicherweise mit der Pluralform eines Substantivs, das eine Ressource beschreibt. Zum Beispiel, "
/customers – URI aller verfügbaren Kunden
/customers/23 – URI eines bestimmten Kunden, dh des Kunden mit der ID=23
/customers/4 – URI eines bestimmten Kunden, dh des Kunden mit der ID=4.
Aber das ist nicht alles. Wir können den URI erweitern, indem wir Bestellungen hinzufügen:
/customers/4/orders – URI aller Bestellungen von Kunde Nr. 4
/customers/1/orders/12 – URI der Bestellung Nr. 12, erstellt von Kunde Nr. 1.
Wenn wir die Erweiterung durch das Hinzufügen weiterer Produkte fortsetzen, erhalten wir:
/customers/1/orders/12/items – URI der Liste aller Produkte in Bestellung Nr. 12, die von Kunde Nr. 1 erstellt wurden.
Beim Hinzufügen von Verschachtelungsebenen ist es wichtig, die URIs intuitiv zu gestalten.
HTTP-Methode
Die HTTP-Methode ist eine Folge beliebiger Zeichen (außer Steuerzeichen und Trennzeichen), die den Hauptvorgang angibt, der an der Ressource ausgeführt wird. Es gibt mehrere gängige HTTP-Methoden. Wir listen diejenigen auf, die in RESTful-Diensten am häufigsten verwendet werden:
GET – Informationen zu einer bestimmten Ressource (über ihre ID) oder zu einer Sammlung von Ressourcen abrufen
POST – Erstellen Sie eine neue Ressource
PUT – Eine Ressource ändern (über ihre ID)
DELETE – Eine Ressource löschen (über ihre ID)
Überschriften
Sowohl Anfragen als auch Antworten enthalten HTTP-Header. Sie übermitteln zusätzliche Informationen zur Anfrage (oder Antwort). Header sind Schlüssel-Wert-Paare. Die Liste der häufigsten Überschriften finden Sie auf Wikipedia . Was REST betrifft, senden Clients in Anfragen an den Server häufig einen „Accept“-Header. Dieser Header wird benötigt, um dem Server mitzuteilen, in welchem Format der Client eine Antwort erwartet. In einer Liste von MIME-Typen sind verschiedene Formate aufgeführt. 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 durch einen Schrägstrich getrennten Teilen – einem Typ und einem Subtyp. Beispiele für MIME-Typen für verschiedene Dateitypen:
Eine Anfrage kann beispielsweise einen Header wie diesen haben:
Accept:application/json
Dieser Header teilt dem Server mit, dass der Client eine Antwort im JSON-Format erwartet.
Anforderungstext
Dies ist die Nachricht, die der Client an den Server sendet. Ob die Anfrage einen Textkörper hat oder nicht, hängt von der Art der HTTP-Anfrage ab. Beispielsweise enthalten GET- und DELETE-Anfragen im Allgemeinen keinen Anfragetext. Aber PUT- und POST-Anfragen können das – es hängt nur vom Zweck der Anfrage ab. Denn um Daten über eine ID (die in der URL übergeben wird) zu empfangen und/oder zu löschen, müssen Sie keine zusätzlichen Daten an den Server senden. Um jedoch eine neue Ressource zu erstellen (über eine POST-Anfrage), müssen Sie die Ressource senden. Das Gleiche gilt für die Änderung einer vorhandenen Ressource. In REST wird der Anforderungstext meist im XML- oder JSON-Format gesendet. Am gebräuchlichsten ist das JSON-Format. Angenommen, wir möchten eine Anfrage an den Server senden, um eine neue Ressource zu erstellen. Wenn Sie es nicht vergessen haben, Wir haben das Beispiel einer Anwendung betrachtet, die Kundenaufträge verwaltet. Nehmen wir an, wir möchten einen neuen Kunden erstellen. In unserem Fall speichern wir folgende Kundeninformationen: Name, E-Mail, Telefonnummer. Dann könnte der Hauptteil der Anfrage der folgende JSON sein:
Bearbeiten Sie Kunde Nr. 1 wie folgt:
Name – Ben
E-Mail – bigben@jr.com
Telefonnummer – +86 (868) 686-8686
DELETE /customers/12/orders/6
Löschen Sie die Bestellung Nr. 6 des Kunden Nr. 12 aus dem System
Antworten
Lassen Sie uns ein paar Worte zu den Serverantworten sagen. Eine 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 bezüglich des Anfragetextes ist alles klar. Die Stelle gibt häufig vom Kunden angeforderte Informationen zurück. Als Antwort auf GET-Anfragen zurückgegebene Informationen können auch im JSON-Format vorliegen. Aber der letzte Teil ist etwas interessanter.
HTTP-Antwortcodes
Betrachten wir die HTTP-Antwortcodes genauer. Ein HTTP-Statuscode ist Teil der ersten Zeile einer Serverantwort auf Anfragen, die über das HTTP-Protokoll gestellt werden. Es ist eine ganze Zahl, die aus drei Dezimalstellen besteht. Die erste Ziffer gibt die Klasse des Antwortstatuscodes an. Auf den Antwortcode folgt normalerweise ein erklärender Satz in englischer Sprache, getrennt durch ein Leerzeichen. Dieser Satz ist ein für Menschen lesbarer Grund für die Antwort. Beispiele:
201 erstellt
401 nicht Autorisiert
507 Nicht genügend Speicherplatz
Der Antwortcode teilt dem Client das Ergebnis der Anfrage mit und ermöglicht es ihm, zu bestimmen, welche Aktionen als nächstes ausgeführt werden sollen. Antwortcodes werden in mehrere Klassen oder Gruppen unterteilt:
1XX – Zur Information
2XX – Diese Codes zeigen an, dass die Anfrage des Kunden erfolgreich empfangen und verarbeitet wurde
3XX – Diese Codes informieren den Client darüber, dass eine zusätzliche Anfrage, normalerweise an einen anderen URI, gestellt werden muss, um den Vorgang erfolgreich abzuschließen
4XX – Clientfehler. Solche Codes können aus einer falsch verfassten Anfrage resultieren. Ein weiteres Beispiel ist der bekannte „404 Not Found“-Code, der auftreten kann, wenn ein Client eine nicht vorhandene Ressource anfordert
5XX – Serverfehler. Diese Codes werden an den Client zurückgegeben, wenn der Server für den Fehler des Vorgangs verantwortlich ist
Damit alles klar ist, analysieren wir die Client-Server-Kommunikation am Beispiel einer RESTful-Anwendung. Angenommen, wir entwickeln eine Webanwendung, die Informationen über Kunden und ihre Bestellungen speichert. Mit anderen Worten: Unser System ist in der Lage, Operationen an bestimmten Entitäten durchzuführen: sie zu erstellen, zu bearbeiten und zu löschen und Informationen über sie anzuzeigen. Diese Einheiten werden sein:
GO TO FULL VERSION