Im Enterprise-Umfeld ist bis heute das Mittel der Wahl zur Kommunikation zwischen Webservices ganz klar SOAP. Wir haben hier eine elektronisch lesbare Schnittstellen-Definition in Form von WSDL-Dateien, wir haben typisierte Daten und weitreichende Tool-Unterstützung. Java, .NET, PHP und viele weitere Programmiersprachen bieten zahlreiche SOAP-Frameworks an.

Warum diese Vorteile ignorieren und stattdessen REST benutzen?

Representational State Transfer

REST-Schnittstellen erschließen sich dem Entwickler einfacher als SOAP-Schnittstellen. Anstelle der WSDL und dem Wissen um den Sinn und Zweck der darin definierten Operationen, benötigt man bei REST nur die URI der Ressource (z.B. http://www.acme.com/basedata/customers/). Um diese Ressource bearbeiten zu können, verwendet man die wohlbekannten Methoden des HTTPs:

• GET – zum Abfragen einer Ressource
  • z.B. GET http://www.acme.com/basedata/customers/4711 zum Abfragen des Kunden mit der Kundennummer 4711
• POST – zum Neu-Anlegen einer Ressource
  • z.B. POST http://www.acme.com/basedata/customers/4712 zum Anlegen des Kunden mit der Kundennummer 4712. Die Kundendaten werden im Body des HTTP-Requests übertragen.
• PUT – zum Neu-Anlegen oder Aktualisieren einer Ressource
  • z.B. PUT http://www.acme.com/basedata/customers/4713 zum Aktualisieren des Kunden mit der Kundennummer 4713 (z.B. neue Post-Adresse). Die Kundendaten werden auch hier im Body des HTTP-Requests übertragen.
• DELETE – zum Löschen einer Ressource
  • z.B. DELETE http://www.acme.com/basedata/customers/4711 zum Löschen des Kunden mit der Kundennummer 4711.
• Weiterhin existieren noch die Methoden PATCH, OPTIONS und HEAD. Siehe dazu z.B. Wikipedia

In der Java-Welt existieren eine Reihe brauchbarer Frameworks, mit denen sich RESTful-Services implementieren lassen (u.a. Spring MVC und Jersey [1]).

Vorteile von REST

Bezogen auf die Ausnutzung der Bandbreite bei der Datenübertragung ist REST leichtgewichtiger als SOAP. REST verwendet mit den Methoden direkt Bestandteile des HTTPs, mit denen die Semantik eines Requests festgelegt wird. SOAP verwendet normalerweise nur HTTP-POST-Requests. In seinem XML-Payload sind also die reinen Nutzdaten enthalten und zusätzlich alle notwendigen Meta-Daten (z.B. Name der aufgerufenen Operation). Anstelle dieses umfangreichen Payloads kann REST das schlankere JSON-Format allein für die Übertragung der Nutzdaten verwenden.

SOAP kann auch aus Sicht eines Firewall-Administrators problematisch sein, da er einem SOAP-Request erstmal nicht ansehen kann, ob er Unternehmensdaten manipulieren wird, also potentiell gefährlich ist, oder ob er nur lesend auf Daten zugreift.

Bei REST kann dazu einfach der Protokoll-Header ausgelesen werden. GET-Requests greifen lesend auf Daten zu, POST, PUT und DELETE manipulieren den Datenbestand. Auch Entwickler können davon profitieren, da man sicherheitsrelevante Mechanismen auf die Netz-Infrastruktur auslagern kann und nicht selbst implementieren muss.

Auch das Caching von Service-Ressourcen wird durch die direkte Verwendung von HTTP erleichtert. Responses auf GET-Requests können durch Webserver, wie z.B. Apache, relativ einfach gecached werden, ohne dass sich die Software-Entwickler damit auseinandersetzen müssen.

Und zu guter Letzt ist die Client-seitige Entwicklung im REST-Umfeld wesentlich einfacher. Der HTTP-Aufruf einer Ressource ist mit einem einfachen HTTP-Client möglich. Das Arbeiten gegen eine SOAP-API beinhaltet normalerweise die Nutzung spezieller Bibliotheken mit größerem Entwicklungsaufwand.

Nachteile von REST

REST bietet im Bereich der Typ-Sicherheit weniger Möglichkeiten als SOAP. Die dort normalerweise verwendete WSDL, der „Schnittstellen-Vertrag“, ist bei REST nicht vorgesehen. Das Serialisieren und De-Serialisieren ist bis heute in SOAP sehr viel einfacher als mit den gängigen REST-Frameworks.

Das Server-seitige Anbieten einer SOAP-Schnittstelle ist mit Bibliotheken, wie beispielsweise Apache CXF, wesentlich einfacher zu realisieren als eine entsprechende REST-Schnittstelle.

Fazit

Besteht die primäre Anforderung darin, dass Schnittstellen-Definitionen eindeutig und Typ-Sicherheit in jedem Fall gegeben sein muss, ist SOAP das Mittel der Wahl. Frameworks wie beispielsweise Apache CXF nehmen dem Entwickler hier viel Arbeit ab und erledigen die entsprechenden Prüfungen und Transformierungen automatisch im Hintergrund.

Doch was ist heutzutage der ausschlaggebende Faktor, mit dem man eine gut gemachte Webservice-Schnittstelle, sowohl Server- als auch Client-seitig, beurteilt?

Performance und Bandbreitennutzung. Beim Zugriff von mobilen Geräten sind diese Faktoren von essentieller Bedeutung. Bei der Kommunikation über mobile Netze kostet jedes unnötig übertragene Byte bares Geld. Dasselbe gilt für stark frequentierte Webservices, ganz unabhängig davon, über welche Art von Netzwerk die Daten abgerufen werden. Unnötig ausgenutzte Bandbreite ist unnötig ausgegebenes Geld, da kommerzielle Web-Provider und CDN-Anbieter ihre Leistungen nach Aufwand abrechnen.

Hier ist REST eindeutig überlegen und deswegen immer dann die bessere Wahl, wenn Performance der bestimmende Faktor ist.

Verweise

• [1] Ein Vergleich von Spring MVC und Jersey http://www.infoq.com/articles/springmvc_jsx-rs