Um diese Frage zu beantworten, ist es nützlich, die Entwicklung der Architektur verteilter Anwendungen von einfachen Schichtarchitekturen über objekt- und dienstbasierte bis hin zu ressourcenbasierten und heute sogar ereignisbasierten Architekturen zu verstehen. Die meisten großen Systeme verwenden eine Kombination von Stilen.
Die ersten verteilten Anwendungen hatten Schichtarchitekturen. Ich gehe davon aus, dass hier jeder weiß, was Schichten sind. Diese Strukturen sind ordentlich organisiert und können Stapel oder zyklische Strukturen sein. Es wird darauf geachtet, einen unidirektionalen Datenfluss aufrechtzuerhalten.
Objektbasierte Architekturen haben sich aus Schichtarchitekturen entwickelt und folgen einem viel lockeren Modell. Hier ist jedes Komponent ein Objekt (oft als verteiltes Objekt bezeichnet). Die Objekte interagieren miteinander über einen Mechanismus ähnlich wie bei Remote-Prozeduraufrufen – wenn sich ein Client an ein verteiltes Objekt bindet, lädt er eine Implementierung der Objektschnittstelle in seinen Adressraum. Der RPC-Stub kann eine Anfrage verarbeiten und eine Antwort erhalten. Ebenso ist die Objektschnittstelle auf dem Server ein RPC-ähnlicher Stub. Die Struktur dieser objektbasierten Systeme ist nicht so ordentlich organisiert, sie sieht mehr wie ein Objektgraph aus.
Die Schnittstelle eines verteilten Objects verbirgt dessen Implementierung. Wie bei geschichteten Komponenten kann die interne Implementierung geändert - sogar komplett ersetzt werden, wenn die Schnittstelle klar definiert ist. Objektbasierte Architekturen bilden die Grundlage für die Kapselung von Diensten. Ein Dienst wird von einer eigenständigen Einheit bereitgestellt, obwohl diese intern andere Dienste nutzen kann. Nach und nach haben sich objektbasierte Architekturen zu dienstorientierten Architekturen weiterentwickelt.
Bei einer dienstorientierten Architektur besteht eine verteilte Anwendung aus Diensten. Diese Dienste können über Verwaltungsbereiche hinweg bereitgestellt werden – sie können über das Internet verfügbar sein (z.B. ein Speicherdienst, der von einem Cloud-Anbieter angeboten wird).
Mit der zunehmenden Popularität von Webservices und der wachsenden Anzahl von Anwendungen, die sie nutzen, wurde die Dienstzusammensetzung (Zusammenführen von Diensten zur Bildung neuer) wichtiger. Eines der Probleme bei der dienstorientierten Architektur war, dass die Integration unterschiedlicher Dienste äußerst kompliziert sein konnte.
Während SOAP ein Protokoll ist, impliziert seine Verwendung eine dienstorientierte Architektur. SOAP versuchte, einen Standard für Dienste bereitzustellen, so dass sie kombinierbar und leicht integrierbar wären.
Ressourcenbasierte Architekturen waren ein anderer Ansatz zur Lösung der Integrationsprobleme von dienstbasierten Architekturen. Die Idee ist, das verteilte System als riesige Sammlung von Ressourcen zu behandeln, die von einzelnen Komponenten individuell verwaltet werden.
Dies führte zur Entwicklung von RESTful-Architekturen. Etwas, das RESTful-Dienste charakterisiert, ist die zustandslose Ausführung. Dies ist anders als bei dienstorientierten Architekturen, bei denen der Server den Zustand verwaltet.
Also... wie vergleichen sich dienstspezifische Schnittstellen, wie sie von dienstorientierten Architekturen (einschließlich solcher, die SOAP verwenden), mit ressourcenbasierten Architekturen wie REST?
Während REST einfach ist, bietet es keine einfache Schnittstelle für komplexe Kommunikationspläne. Wenn beispielsweise Transaktionen erforderlich sind, ist REST nicht geeignet; es ist besser, den komplexen Zustand auf dem Server zu kapseln, als den Client die Transaktion verwalten zu lassen. Es gibt aber viele Szenarien, in denen die orthogonale Verwendung von Ressourcen in RESTful-Architekturen die Integration von Diensten wesentlich vereinfacht, was sonst eine Vielzahl von Dienstschnittstellen bedeuten würde. Ein weiterer Kompromiss besteht darin, dass ressourcenbasierte Architekturen mehr Komplexität auf den Client bringen und den Datenverkehr über das Netzwerk erhöhen, während dienstbasierte Architekturen die Komplexität des Servers erhöhen und seine Speicher- und CPU-Ressourcen belasten.
Einige Leute haben auch häufig HTTP-Dienste oder andere Dienste erwähnt, die nicht den Anforderungen von RESTful-Architektur oder SOAP entsprechen. Auch diese können entweder als dienstbasiert oder ressourcenbasiert kategorisiert werden. Sie haben den Vorteil, einfacher zu implementieren zu sein. Man sollte nur einen solchen Ansatz verwenden, wenn man weiß, dass der Dienst nie über Verwaltungsbereiche hinweg integriert werden muss, da dies keine Versuch unternimmt, die auftretenden Integrationsprobleme zu lösen.
Diese Arten von HTTP-basierten Diensten, insbesondere Pseudo-RESTful-Dienste, sind nach wie vor die häufigsten Typen. Die Implementierung von SOAP ist kompliziert und sollte nur verwendet werden, wenn dies wirklich notwendig ist – d.h. wenn ein Dienst benötigt wird, der leicht über Domains hinweg integriert werden kann und eine Dienstschnittstelle haben soll. Es gibt immer noch Fälle, in denen dies erforderlich ist. Ein echter RESTful-Dienst ist ebenfalls schwierig zu implementieren, wenn auch nicht so schwierig wie SOAP.
