REST versus SOAP: Wie Sie den besten Web-Service wählen
Ob REST oder SOAP der richtige Ansatz ist, entscheidet jeweils der Anwendungsfall. Unser Experte erläuterte REST und SOAP anhand des Online-Handels.
Fast jeder Softwarearchitekt baut Programme, die über ein Web-Frontend Anwendungen für Inventarisierung, Versand, Rechnungswesen und Ressourcen-Planung (ERP) mit Daten füttern. Diese Art von Software verwendet in der Regel einen Webserver für das Frontend, einen Anwendungsserver als Brücke zur primären Anwendung sowie Business-Softwarekomponenten. Diese werden in ähnlicher Form auch im Handel verwendet. Der Prozess von der Web- zur Desktop- oder Mobilanwendung lässt sich zur Beschreibung von Anwendungsfällen für Representational State Transfer (REST) und Simple Object Access Protocol (SOAP) verwenden.
Aus Sicht des Webs ist ohne Zweifel REST der beste Ansatz. Annähernd jedes Gerät - vom Smartphone bis zum Computer - hat mittlerweile einen Internet-Browser, der URLs nutzt. Dieser öffnet eine Website und initiiert eventuell eine Verkaufsanwendung. In diesem Fall geht das RESTful-Design davon aus, dass ein Auftrag erfolgt. Die Transaktion ist aber erst abgeschlossen, wenn der Auftrag zur Zufriedenheit des Nutzers beendet ist (zum Beispiel nach Erhalt des Produkts).
Typischen Prozesse im Handel umfassen:
- Bestellungen erstellen,
- Produktinformationen lesen,
- Bestellungen aktualisieren sowie
- Versendung und Abschluß der gesamten Bestellung.
Der Anwendungsserver bildet dabei die Verbindung zwischen Online- und Desktop- beziehungsweise Mobilgerätanwendung. Diese Schicht bearbeitet die Bestellungen. Dazu gehört unter anderem, mögliche Kunden über die Verfügbarkeit zu informieren und Produktinformation anzubieten. Befindet sich ein Produkt nicht im Lager, wird die Bestellung verhindert. Die Rückmeldung zum Nutzer erfolgt per E-Mail, wenn die Transaktion im Web abgeschlossen ist.
REST oder SOAP: Anwendungsfall entscheidet
Meist bilden die Applikations-Server lediglich das Frontend der bestehenden Software ab. Typischerweise basieren diese Applikationen auf einer manuellen Auftragsabwicklung oder werden vom einem Kundenbetreuer genutzt. Die Bestellkoordinierung durch einen Menschen schafft Unklarheiten beim Kunden während des Vorgangs aus der Welt. Koordiniert kein menschlicher Vermittler die Bestellverarbeitung, muss der App-Server sicherstellen, dass die Transaktion vollständig ausgeführt wird. Ansonsten erhält ein Kunde kein Produkt oder führt die Bestellung noch einmal aus, was zu Duplikaten führt.
REST lässt sich verwenden, um die Bestellung in den folgenden Instanzen abzuschließen:
- ein Produkt ist auf Lager und die Anzahl der Bestellungen führt üblicherweise nicht dazu, dass es ausverkauft ist; oder
- ein Kunde wird nach der eingehenden Bestellungen darüber informiert, dass ein Produkt aufgrund von vielen Bestellungen nicht auf Lager ist.
Der Applikations-Server ist der Bereich, an dem sich die RESTful-Verarbeitung in den Arbeitsablauf integriert. Erfordert die Auftragsbearbeitung die Bestätigung der Verfügbarkeit bevor die Transaktion im Internet abgeschlossen ist, muss das System dem Kunden eine Rückmeldung sofort geben.
Mehr zum Thema Softwarearchitektur und SOA:
Unser Experte erläutert Ihnen, wie sich Mit REST und Cloud Bursting die Leistung von SOA- und Cloud-Anwendungen verbessern lässt.
Um das Thema SOA und Cloud Computing ranken sich viele Mythen. Wir räumen mit drei Missverständnissen aus.
Eine Serviceorientierte Architektur (SOA) lässt sich auch für Big Data und das Cloud-Datenmanagement einsetzen.
Wenn ein etabliertes System einen Auftrag bestätigt und die Web-Transaktion verloren geht bevor sie abgeschlossen ist, muss die Bestellung zusätzlich gesichert werden. Das bedeutet, der App-Server erhält einen Auftrag für jedes bestellte Produkt. Dabei muss er in der Lage sein, alle Bestellung rückgängig zu machen, sollte die Bestellung scheitern oder durch einen Nutzer abgelehnt werden. SOAP ist deutlich besser, wenn um die Aufrechterhaltung bestimmter Bestellphasen geht. Eine zustandsorientiertes SOAP kann Transaktionen während des gesamten Zyklus beibehalten – parallel zur Aktivität des Webservers.
REST versus SOAP: Was bei der Entscheidung hilft
RESTful-Komponenten sind nicht so leistungsfähig für geschäftskritische Prozesse. Sie arbeiten am besten, wenn eine Bestellung nur ein einzelner Vorgang ist, auch wenn er mehrere Bereiche umfasst. Wenn der Bestellprozess nicht über eine einfache Website bearbeitet werden kann, ist REST im Vergleich zu SOAP ungeeignet. Sollen mehrere Transaktionen gleichzeitig geschehen, müssen sie auf SOAP übertragen werden.
Ob REST oder SOAP eingesetzt wird, hängt von der Leistung und Zuverlässigkeit ab. Wenn ein Kunde Zeit investiert, die Produktkataloge und Bewertungen zu durchforsten, bevor er eine Kaufentscheidung trifft, dann sind mehrere Web-Frontends zur Unterstützung mehrerer Nutzer notwendig, sollte es zu hohen Auslastungen kommen.
Auf der Ebene des Webservers (REST) läuft das Aufteilen von Ladezeit und möglichen Ausfällen automatisch ab. Das passiert, da das Kundensystem einen Zustand aufrechterhalten und der Webserver auf alle Anfragen reagieren muss, auch wenn zum Beispiel ein anderer Server eine frühere Phase des Bestellvorgangs bearbeitet hat. Der Anwendungsserver und die einzelnen Komponenten benötigen eine spezielle Behandlung bei der Unterstützung der Ladezeit-Aufteilung.
Wenn SOAP verwendet wird, ist es möglich, mehrere Status mit einer Backend-Datenbank zu verwalten, die die verschiedenen Phasen der Transaktion mit unterschiedlichen Anwendungskomponenten synchronisiert. Dieser Prozess erfordert eine zuverlässige Datenbank, so dass der aufgeteilte Status während des Bestellvorgangs nicht durch den Ausfall einer Komponente oder Abbruch einer Transaktion kontaminiert wird. Wenn sich die Workloads stark unterscheiden oder der Abbruch von Transaktionen häufig vorkommt, ist eine sorgfältige Gestaltung der SOAP-basierten Anwendung ausschlaggebend bei der Vermeidung von Status-Problemen und der Datenbank-Integrität.
Lassen sich hieraus Regeln ableiten? Für Anwendungen, die Kunden (speziell mobile Anwender mit hohen Abbruchraten) online unterstützen, sollte das REST-Verhalten soweit wie möglich kontrolliert werden, um flexibel zu sein. Wenn man bestehende Anwendungen nutzt, insbesondere bei Applikationen für den Kunden-Support, sollte ein neues Element auf dem Anwendungsserver erstellt werden, um eine Grenze zwischen webbasierter Verarbeitung und Anwendung zu ziehen.
Über den Autor: Tom Nolle ist Präsident von CIMI, einem strategischen Beratungsunternehmen im Bereich Tele- und Datenkommunikation.
