NETWAYS Blog

Vor einiger Zeit sind wir ja bereits auf SOAP intensiv eingegangen. SOAP ist zwar zu Beginn oft Komplex und konfrontiert die Entwickler mit einer etwas anstrengenderen Lernkurve, spielt jedoch auf der Geraden den ein oder anderen Vorteil in Bezug auf komplexe Übermittlungen in heterogenen Umgebungen aus.
REST steht für REpresentational State Transfer und beschreibt ein Architekturmodell, dass man täglich an vielen Stellen des WWW, seinem logischen Vorbild, wiederfindet. Während SOAP „nur“ ein Transfermedium von Nachrichten ist, hat REST eine konkrete Vorstellung wie mit entsprechenden Schnittstellen umgegangen wird.
Hierfür stehen die klassischen Web-Methoden GET, POST, PUT und DELETE zur Verfügung. Abhängig von Ihrer Verwendung ist somit auch die grundlegende Funktion beschrieben.
Ein Beispiel:
[code lang=“xml“]
GET
[/code]
Hier ist klar zu erkennen, dass die Ressourcenauflösung über Pfade dazu verwendet wird ein Objekt eindeutig zu identifizieren und den Status zu ermitteln. Soll ein neuer Status hinzugefügt werden, kann das folglich mit einem POST-Request erfolgen. Die Ausgabe des REST-Kommandos ist im Vergleich zu SOAP nicht im Detail spezifiziert, jedoch wird häufig XML verwendet, da sich die Weiterverarbeitung deutlich einfacher gestaltet. Über den Verweis auf anderer REST-Ressourcen mit Hilfe der sogenannten XLinks’s können auch hierarchische Beziehungen abgebildet und aufgelöst werden.
In dieser Einfachheit liegt der klare Vorteil von REST, da sich der Entwickler, mit Ausnahme der strukturierten Verzeichnisauflösung, an keine definierten Übertragungsformate halten muss und die Anwendung leichtgewichtig gestalten kann. Daraus ergibt sich jedoch auch eine stark verzahnte Kommunikationsebene zwischen Client und Server, da der Spezifikation kein Routingmodell hinterlegt ist.
Die Entscheidung für SOAP oder REST ist, wie bereits im vorhergehenden Artikel erläutert, abhängig vom Bedarf an Komplexität und der Möglichkeit komplexere Transaktionen zu bündeln und zu routen. Der überwiegende Teil an Systemen wird jedoch leicht mit REST auskommen und von den agilen Möglichkeiten profitieren.

Bernd Erk

CEO

---

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.

Lies mehr von Bernd und triff unser Team

Wie vor einigen Wochen versprochen, möchte ich heute einmal auf das SOAP-Protokoll eingehen. SOAP steht für Simple Object Access Protocol, besser gesagt stand. Seit den letzteren Versionen hat man dieses Akronym aufgrund der hohen Komplexität, die zugegeben mit Simple nicht viel zu tun hat, aufgegeben.
Als Protokoll beschreibt SOAP unter Nutzung von XML eher den Aufbau einer Nachricht als die eigentliche Übertragung. Eine SOAP-Nachricht besteht aus einer Hülle, dem so genannten SOAP-Envelop und beinhaltet einen entsprechenden Header und Body. Während der SOAP-Header optional ist, muss der Body ausgeführt sein und kann noch ein entsprechendes SOAP-Fault Element enthalten um Fehlersituationen zu übermitteln.
Ein Beispiel für eine gültige SOAP-Nachricht:
[code lang=“xml“]
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.icinga.org/status">
<m:GetStatus>
<m:ServerStatus>srv-lin-01</m:StockName>
</m:GetStatus>
</soap:Body>
</soap:Envelope>
[/code]
Zwar ist HTTP oder HTTPS der häufigste Standard um entsprechende Nachrichten zu übermitteln, es ist jedoch auch eine alternative Nutzung von JMS, SMTP oder anderen Transportmodellen möglich.
Im Unterschied zu REST, dazu bald mehr, ist SOAP kein leichtgewichtiges Unterfangen. Es Bedarf wohl definierten Schnittstellen und Namespaces um sich bei verschiedenen Services in größeren Umgebungen nicht in die Quere zu kommen und ist aufgrund des entsprechenden XML-Overheads bei der Übertragung von großen Datenmengen nicht besonders performant. Diese Nachteile verlieren durch immer größere Bandbreiten und entsprechende Performance jedoch zunehmend an Bedeutung und auch die entsprechende XML-Parser haben in Sachen Geschwindigkeit ordentlich zugelegt.
Der große Vorteil von SOAP liegt darin, dass ein entsprechender Service genau auf die Beantwortung bestimmter Requests vorbereitet werden muss und somit schon auf Schnittstellenebene gewisse Unstimmigkeiten eliminiert werden können. Ein „ungefähr“ Request wird freundlich vom Server zurückgewiesen und vermeidet eine fehlerhafte Verarbeitung auf Definitionsebene.
Die beliebige Komplexität eines SOAP-Envelops ermöglicht jedoch die Zusammenfassung komplexer Transaktionen und Strukturen in einer Nachricht. So kann der Overhead der Einzelabfrage reduziert werden und komplexe Zusammenhänge einfacher dargestellt werden als durch Abbildung einer Vielzahl von REST-Requests.
Eine Entscheidung zugunsten von SOAP sollte nur bei Notwendigkeit der entsprechenden Komplexität fallen, ist dann aber oft auch sinnvoll.
Handle with Care!

Bernd Erk

CEO

---

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.

Lies mehr von Bernd und triff unser Team