8.1 Remote-API-Ansatz
Beim Aufbau einer Client-Server-Architektur machen alle Programmierer den gleichen Fehler. Sie beginnen, Anfragen an den Server als Methodenaufrufe zu behandeln .
Wenn Sie den Berichterstellungsprozess auf dem Server starten möchten, senden Sie ihm doch eine Anfrage wie:
http://server.com/startDocumentGeneration?paramsUnd wie lade ich den Bericht herunter, nachdem er fertig ist? Dazu schreiben wir eine andere Methode:
http://server.com/getDocumentDer Server speichert HttpSessionInformationen zu unserem Dokument und sobald das Dokument generiert ist, gibt der Server sie zurück.
Toller Ansatz. Oder nicht?
Der Ansatz ist wirklich schrecklich. Die Sache ist, dass sich der Server die Dokumentnummer merken muss. Mit anderen Worten: Um neue Methodenaufrufe ordnungsgemäß verarbeiten zu können, muss sich der Server die Ergebnisse früherer Methodenaufrufe merken.
Im Internet ist das ein großes Problem. Das Internet verschwindet möglicherweise, der Browser wird möglicherweise geschlossen. Die Seite kann neu geladen werden oder versehentlich auf einen Link geklickt werden usw. Und der Server speichert weiterhin Megabytes an Daten aus früheren Benutzeranfragen ...
Für ein komfortables Arbeiten mit dem Server können Sie nicht erwarten, dass Sie immer die Daten früherer Anfragen an den Server zur Hand haben.
Wie ruft man dann Methoden des Servers auf? Die richtige Antwort wäre schrecklich: Auf keinen Fall!
8.2 REST-Ansatz
Die Programmierer besannen sich wieder auf das Wesentliche und erinnerten sich, dass die Anfrage zunächst den Pfad zur Datei auf dem Server enthielt:
http://server.com/path?paramsUnd wir haben uns entschieden, diesen Ansatz maximal zu nutzen.
Nun wird der Server als Datenspeicher betrachtet , der nach außen in Form eines Baums sichtbar ist .
Wenn Sie eine Liste aller Benutzer erhalten möchten, rufen Sie die Abfrage auf:
http://server.com/usersWenn Sie Daten zu Benutzer 113 abrufen möchten, führen Sie die Abfrage aus:
http://server.com/users/113Und so weiter, alles in der gleichen Richtung.
Auch hier wird der Server als Datenspeicher betrachtet, der nach außen in Form eines Baums sichtbar ist.
Daten können empfangen werden – GET- Anfragen , geändert – POST- Anfrage und gelöscht – DELETE -Anfrage .
8.3 Kein Staat
Das REST-Protokoll der Interaktion zwischen Client und Server erfordert die folgende Bedingung: Während des Zeitraums zwischen Anfragen des Clients werden keine Informationen über den Status des Clients auf dem Server gespeichert.
Alle Anfragen des Clients müssen so gestaltet sein, dass der Server jedes Mal alle Informationen erhält, die er zur Erfüllung der Anfrage benötigt . Der Sitzungsstatus wird auf der Clientseite gespeichert.
Während der Bearbeitung von Kundenanfragen wird davon ausgegangen, dass sich der Kunde in einem Übergangszustand befindet. Jeder einzelne Anwendungsstatus wird durch Links dargestellt, die beim nächsten Aufruf des Clients aufgerufen werden können.
8.4 Schnittstelleneinheitlichkeit
Alle zum Abrufen von Objekten vom Server verwendeten Pfade sind standardisiert. Dies ist sehr praktisch, insbesondere wenn Sie Daten von anderen REST-Servern beziehen.
Alle Objektschnittstellen müssen drei Bedingungen erfüllen:
Ressourcenidentifikation
Alle Ressourcen werden in Anfragen mithilfe eines URI identifiziert. Die Ressourcen innerhalb des Servers sind von den Ansichten getrennt, die an die Clients zurückgegeben werden. Beispielsweise kann ein Server Daten aus einer Datenbank als HTML, XML oder JSON senden, wobei es sich bei keinem dieser beiden Speichertypen um einen Speichertyp innerhalb des Servers handelt.
Bearbeiten von Ressourcen über eine Ansicht
Wenn der Client eine Darstellung der Ressource einschließlich Metadaten speichert, verfügt er über genügend Informationen, um die Ressource auf dem Server zu ändern oder zu löschen.
„Selbstbeschreibende“ Nachrichten
Jede Nachricht enthält genügend Informationen, um zu verstehen, wie damit umzugehen ist. Wenn Sie beispielsweise Informationen über den Benutzer benötigen, gibt Ihnen der Server ein JSON-Objekt zurück, in dem sich Namens- und Adressfelder befinden.
Es sollte nicht vorkommen, dass der Kunde wissen muss, dass die erste Zahl in der Antwort das Alter und die zweite das Geburtsdatum angibt.
8.5 Caching
Der REST-Ansatz geht davon aus, dass Datenanfragen über das HTTP-Protokoll erfolgen. Daher werden Objekte durch Aufrufen einer GET-Anfrage abgerufen. Das bedeutet, dass sie, wie alle über eine GET-Anfrage empfangenen Ressourcen, allen Regeln für das Caching von HTTP-Ressourcen unterliegen.
Das heißt, über die REST-API empfangene Daten werden auf die gleiche Weise zwischengespeichert wie alle statischen Ressourcen auf Webservern. Schönheit :)