Africa Studio - stock.adobe.com
Sechs wesentliche Einschränkungen der REST-Architektur
Obwohl ein REST-Design nicht schwierig ist, gibt es einige Regeln, an die sich Entwickler und Architekten halten müssen. Hier sind sechs Einschränkungen einer REST-Architektur.
Der Begriff architektonische Einschränkungen bezieht sich auf die Merkmale, die eine Architektur aufweisen muss, um der Definition eines bestimmten Modells zu entsprechen. Durch die Einhaltung der spezifischen Regeln, die die Grundlage für diese Architektureinschränkungen bilden, ist es einfacher zu verstehen, was etwas als RESTful definiert. Zudem lassen sich Probleme vermeiden, die Anfängern in diesem Architekturmodell oft Kopfschmerzen bereiten.
Leider lassen viele Softwarearchitekten Praktiken zu, die gegen die REST-Prinzipien verstoßen, und glauben dennoch, dass sie das RESTful-Design beherrschen. Es ist jedoch ratsam, wenn sie lernen, dass an den grundlegenden Anforderungen, die dieses Architekturmodell definieren, kein Weg vorbeiführt.
Untersuchen wir die sechs grundlegenden Einschränkungen der REST-Architektur, die jeder als Leitfaden für deren Implementierung verwenden sollte, einschließlich der Gründe, warum sie so wichtig sind, und der taktischen Entwicklungs- und Designpraktiken, die sie mit sich bringen.
Einheitliche Schnittstelle
Die erste Einschränkung der REST-Architektur ist eine einheitliche Schnittstelle. In einem RESTful-Design ist es hilfreich, einzelne Dienste als Anwendungsressourcen zu konzipieren, die ihre eigene individuelle Client-Schnittstelle bereitstellen.
Es ist wichtig, dass diese Ressourcen in Bezug auf Umfang und Datenvolumen so klein sind, dass eine einzige Schnittstelle sie problemlos handhaben kann. Schließlich verlangt REST, dass die Schnittstellenmechanismen, die diese Ressourcen verwenden, um ihre Fähigkeiten darzustellen, sich konsistent zu allen anderen Schnittstellen verhalten, die verwandte Dienste darstellen.
Dies ist eine leicht zu erfüllende Bedingung, vorausgesetzt, die Architekten bemühen sich, diese Ressourcen als Substantive zu behandeln, das heißt als eindeutige Einheiten, die Eingaben entgegennehmen und Aufrufe in Form von Verfahrensanweisungen für eine bestimmte Operation interpretieren. Dies ist ein grundlegendes Prinzip der objektorientierten Programmierung: Dienste als Objekte zu behandeln, die Befehle entgegennehmen. Ein einfacher Weg, sich dies zu merken, ist, sich vorzustellen, dass man Aktionen an Objekte und nicht Objekte an Aktionen sendet.
Beachten Sie, dass es für Architekten auch wichtig ist, in Bezug auf Ressourcendefinitionen und API-Designs konsistent zu bleiben, damit die Ressourcen nicht fälschlicherweise der falschen API oder Client-Schnittstelle zugeordnet werden und Daten gemeinsam nutzen.
Client-Server-Modell
Die nächste Einschränkung ist das Client-Server-Modell, das besagt, dass die Kopplung zwischen einer RESTful-Ressource und den zugehörigen APIs nur in der Client-seitigen Schnittstelle bestehen soll. Diese Ressourcen können sich unabhängig voneinander weiterentwickeln, aber die Schnittstelle muss intakt bleiben.
Diese lose Kopplung trägt dazu bei, schlecht verwaltete Abhängigkeitsbeziehungen zu reduzieren, die zu Unterbrechungen führen und Aktualisierungsprozesse erschweren, was von entscheidender Bedeutung ist, wenn Entwickler häufig Ressourcen und Clients isoliert erstellen. Dies erleichtert auch die Zusammenarbeit von Softwareteams auf der Ebene, auf der Backend-Entwicklung und Frontend-Design zusammentreffen, da die Gefahr geringer ist, dass die Entwickler eine Änderung vornehmen, die plötzlich die Funktionalität der Schnittstelle beeinträchtigt oder verändert.
Zustandslos
Zustandsloses Verhalten ist ein besonders wichtiges Merkmal von REST-Architekturen. Zustandslosigkeit bedeutet, dass der Server, der die Anwendungsressourcen bereitstellt, keine Informationen zwischen Anfragen speichert oder eine bestimmte Verarbeitungsreihenfolge für Aufrufe und Anfragen erzwingt. Die Ausgabe jeder Anfrage sollte ausschließlich auf der Grundlage des Inhalts der Anfrage und der angegebenen Operation priorisiert werden – nicht auf Grundlage früherer Verhaltensweisen hinsichtlich der Abfolge von Ereignissen oder der Reihenfolge von Operationen.
Diese Eigenschaft ist der Schlüssel zu den Skalierbarkeits- und Ausfallsicherheitseigenschaften von Diensten, denn sie bedeutet, dass jede Instanz einer Ressource eine Anfrage auf die gleiche Weise erfüllt, unabhängig von übergeordneten Verarbeitungsplänen. Ein zustandsloses Design ist jedoch kompliziert zu realisieren, insbesondere wenn häufige Anfragen erhebliche Mengen an zustandsbezogenen Daten enthalten. Am einfachsten ist es, wenn die Speicherung interner Daten zwischen den Ressourcenanforderungen, einschließlich der spezifischen Abfolge von Aufrufen und Anforderungen, ganz vermieden wird.
Cache
Die Einschränkung, die Architekten am meisten zu verwirren scheint, ist die Anforderung der Cache-Fähigkeit. Im Wesentlichen ist eine Architektur Cache-fähig, wenn die Antwort eines Servers in einem zwischengeschalteten und im Idealfall abstrahierten Repository gespeichert werden kann. Bei Bedarf kann dieses Repository diese zwischengespeicherten Antworten für die Wiederverwendung an einem bestimmten Ort anbieten und garantieren, zumindest für einen bestimmten Zeitraum, dass sich das Verhalten dieser Antworten nicht ändert.
Nicht alles muss zwischengespeichert werden können, um diese Bedingung zu erfüllen, aber jede Antwort, die leicht und kostengünstig zwischengespeichert werden kann, muss identifiziert werden. Darüber hinaus muss der Cache jederzeit in der Lage sein, neue Anfragen zu stellen, wenn er anstelle des Servers Workloads sicher bewältigt.
Wenn die Antworten des Servers und die von ihnen bereitgestellten Ressourcen nicht Gegenstand geplanter Aktualisierungen oder Funktionsänderungen sind, ist es ratsam, diese Informationen in die Antworten des Servers an den Client aufzunehmen. Auf diese Weise können überlastete Anwendungssysteme zuverlässig auf den Cache zurückgreifen, wenn sich die Antworten verzögern oder der Server ausfällt.
Mehrschichtiges Systemmodell
Die fünfte Einschränkung der REST-Architektur ist das Modell des Schichtensystems, das besagt, dass eine Anwendung in der Lage sein sollte, Ressourcen zu definieren, indem sie sie Funktionsschichten zuordnet, wobei jede Schicht einer einzelnen, gemeinsam genutzten Dienstfunktion entspricht. In einigen Fällen kann es sich bei diesen Fähigkeiten um etwas Einfaches handeln, wie zum Beispiel Lastausgleichsaktivitäten. In anderen Fällen kann die Schicht einen komplexeren Prozess beherbergen, der mehrere Server und Softwareelemente erfordert, wie zum Beispiel die Verarbeitung großer Datenmengen.
Wie bei der bereits erwähnten Einschränkung der Cache-Fähigkeit ist es nicht notwendig, jeden einzelnen RESTful-Dienst in eine eigene Schicht zu unterteilen. Konzentrieren Sie sich stattdessen einfach darauf, das Schichtenmodell bei Bedarf vollständig unterstützen zu können. Glücklicherweise ist die Implementierung eines Schichtenmodells in der Praxis relativ einfach, sofern die Architektur darauf vorbereitet ist.
Code on Demand
Code on Demand ist die letzte Einschränkung und die Einzige, die als optional betrachtet wird. Code on Demand besagt, dass RESTful-Ressourcen bei der Antwort auf Anfragen darauf vorbereitet sein sollten, Code bereitzustellen, der auf der Client-Seite und nicht auf der Server-Seite (oder irgendwo dazwischen) ausgeführt wird. Die Bereitstellung von Client-seitigem Code ermöglicht es, die Arbeit zu verteilen, wenn die Server-seitige Ausführung zu Fehlern oder Leistungsproblemen führen.
Um Code on Demand in die Praxis umzusetzen, muss man ein wenig über die Fähigkeiten der Clients, die auf eine Ressource zugreifen, zur Codeausführung wissen. Dazu muss der Server bestimmte Client-seitige Fähigkeiten identifizieren, um sicherzustellen, dass der Code auch wirklich wie erwartet ausgeführt wird. In der Regel wird dies durch die Verwendung einer Allzweckprogrammiersprache erreicht, die von den meisten der zugehörigen Anwendungskomponenten unterstützt und während eines Codeaustauschs verstanden wird.
