Webservices Schnittstellen: SOAP und RESTful

In diesem Technik-Beitrag möchten wir gerne die Webservice-Schnittstellen SOAP und REST gegenüberstellen. webPDF stellt seine PDF-Funktionen sowohl als SOAP- als auch als RESTful-Webservices zur Verfügung. Aber wie unterscheiden sich die Methoden SOAP und RESTful und was sind die Vor- und die Nachteile?

Beim Thema Softwareentwicklung fällt häufig das Stichwort API oder RESTful API. Da APIs als Grundstein der Software-Entwicklung gelten, lohnt sich ein Blick hinter die Kulissen, um zu verstehen, worum es hier geht. API bedeutet in diesem Zusammenhang (als Abkürzung) Application Programming Interface, also so etwas wie „Programmierschnittstelle“. Durch Schnittstellen wird eine Kommunikation und Interaktion zwischen zwei Systemen möglich. Neben dem Design gehört es also inzwischen bei der Entwicklung einer Website immer dazu, eine API zu entwerfen (samt einer verständlichen Dokumentation dafür). Und für diese Arbeit haben sich inzwischen bestimmte Standards etabliert (Protokolle) mit denen jeder API-Designer arbeitet. Eines dieser bekanntesten Protokolle ist beispielsweise SOAP.

Gegenüberstellung Webservice Schnittstellen: SOAP & RESTful

SOAP (Simple Object Access Protocol)	REST (Representational State Transfer)
Netzwerkprotokoll	REST gilt als ein Software-Architekturstil / Bauweise für das Web
Einsatzgebiet: SAP, Verwendung im Enterprise Umfeld	Einsatzgebiet: Web / Verwendung bei öffentlichen Web APIs
SOAP gilt als ein Standard des World Wide Web Consortiums (W3C). Dabei stützt sich SOAP auf XML und auf Internet-Protokolle bei der Übertragung von Nachrichten. In der Regel wird eine Kombination von SOAP mit HTTP und TCP genutzt.	Charakteristischerweise funktioniert die REST-Bauweise so, dass die Kommunikation auf Abruf erfolgt. Die Ressourcen, welche die gewünschten Objekte der Anwendung sind, besitzen jeweils eine individuelle URI (Uniform Resource Identifier) mit der sie identifiziert werden können.
Stateless Webservices: In Gegenüberstellung zu RESTful wird SOAP häufig als stateless bezeichnet. Das heißt, dass Informationen bei jeder Anfrage komplett mitgegeben werden und danach wieder vergessen werden. Das klassische Beispiel ist das HTTP-Protokoll: Wenn ein Browser eine Webpage von einem Webserver anfordert, dann liefert der Webserver den Inhalt und geht danach wieder in einen zustandslosen/ statuslosen Zustand über ohne jegliche Erinnerung. Jede neue Anfrage des Clients erfordert einen neuen Verbindungsaufbau und erneute Datenbeschaffung. Durch die Kombination von SOAP mit HTTP wird SOAP häufig als stateless bezeichnet. (Dazu muss man sagen, dass selbst ein stateless http Protokoll Cookies haben kann, welche Stateful -Transaktionen ermöglichen.) Stateles Webservices allgemein gelten als einfach zu entwickeln und besser skalierbar.	Stateful Webservices: In Abgrenzung zu SOAP kann man hervorheben, dass ein stateful Webservice bedeutet, dass der Server Informationen über den Client speichert und diese Informationen innerhalb einer Serie von Anfragen nutzen kann. So ein zustandsbehafteter Webservice ist Session orientiert, das heißt man kann bei der Übermittlung größerer Datenmengen Ressourcen sparen und die Geschwindigkeit erhöhen. Beispiel für einen zustandsorientierten Webservices: Ein Checkout-Prozess bei einem Online-Shop. Stateful heißt hier also: Die Daten stehen auf jeder Seite über die gesamte Session zur Verfügung. Das führt evtl. zu großer Last auf dem Server/ Die Programmierung gilt aber in diesem Fall als leichter.
Nachteile von SOAP: Es bringt einen zusätzlichen Overhead (viele Metadaten) durch XML mit (kann sich sich auf die Performance auswirken). Das Zusammenbauen der XML-Nachrichten ist rechenintensiv und außerdem wurden die WS-standard im Laufe der Zeit sehr unübersichtlich.	REST dient, wie SOAP (oder WSDL und RPC) also vor allem der Kommunikation zwischen Maschinen. REST hat sich hier als besonders hilfreich erwiesen, da es anders als SOAP keine Methodeninformationen kodiert. Man kann sich einfach an der bereits vorhandenen Web-Infrastruktur orientieren.
Vorteile von SOAP: Es gilt als intuitiv und bietet eine enorme Freiheit bei der Umsetzung, dabei ist es sehr komplex. Es bietet eine allgemein akzeptierte Standardisierung, Plattformunabhängigkeit und Skalierbarkeit.	Nachteil von REST: Im Gegensatz zu SOAP fehlt es an Standardisierung, das kann Missverständnisse hervorrufen. Vorteil: RESTful eignet sich vor allem dann, wenn es darum geht, Daten zu erhalten und gegebenenfalls anzuzeigen. Zudem kann man RESTful sehr einfach implementieren. Und noch ein positiver Nebeneffekt ist: Der Client kann die Aufrufe an unterschiedliche Server schicken, je nach Last. Als Vorteile überwiegen hier die Unabhängigkeit der Clients und die komfortable Skalierbarkeit der Dienste. REST kann immer unabhängig von der verwendeten Implementierungstechnologie des Servers eingesetzt werden und wird bei der Entwicklung mobiler APIs bevorzugt. Die Vereinbarkeit mit der bestehenden Web-Infrastruktur macht die Verwendung von REST besonders modern zukunftssicher.

webPDF 6.0: SOAP oder RESTful – Alle technischen Details

Zusammenfassend kann man sagen, dass es auf den jeweiligen Einzelfall ankommt, um zu entscheiden, ob man SOAP oder RESTful einsetzen möchte. Da beide Methoden Vor- und Nachteile haben, bietet webPDF beides an! Denn Webservices sind für die unterschiedlichsten Anwendungsszenarien denkbar und haben eine offene und flexible Architektur, was sie unabhängig von Plattformen, Programmiersprachen oder Protokollen macht. Man kann durch sie Lizenzkosten vermeiden und Webservices sehr flexibel vielerorts einsetzen. So macht es Sinn sich je nach Fall für SOAP oder für RESTful zu entscheiden.

Webservice Schnittstellen bei webPDF:

SOAP

RESTful

webPDF 6.0 stellt seine Schnittstellen als SOAP-Webservices gemäß der „Java Specification Request (JSR) 224“ zur Verfügung. Die Beschreibung des Interface wird als „Web Services Description Language (WSDL)“ bereit gestellt. Der webPDF-Server hält die SOAP-Webservices auf Basis „JAX-WS 2.2“ und dem „JAX-WS Reference Implementation (RI) Project“ in der Version 2.2.8 bereit. Der webPDF-Server stellt eine Reihe von SOAP-Webservices mit verschiedenen SOAP-Methoden zur Verfügung.

webPDF 6.0 bietet sein Interface als RESTful-Webservices gemäß der „Java Specification Request (JSR) 311“ an. Die Bereitstellung basiert auf den Web-Standards und dem HTTP-Protokoll. Die Funktionen von webPDF werden als REST (Representational State Transfer) Ressourcen verfügbar gemacht und können über einen Uniform Resource Identifier (URI) angesprochen werden. Die Darstellung der Ressourcen erfolgt in JSON. Der webPDF-Server ermöglicht die RESTful-Webservices auf Basis von JAX-RS 2.0 und der Jersey-Referenzimplementierung. Per HTTP-Methoden PUT, GET, POST und DELETE sind die URIs der Webservices ausführbar.

webPDF-Webservices

webPDF bietet also alle PDF-Funktionen als SOAP- oder auch als RESTful Webservices an. Webservices sind äußerst komfortabel, da sie plattform-unabhängig verwendbar sind. Hinzu kommt, dass sich die Webservices in Programmiersprachen integrieren lassen. Sowohl bei der Nutzung von SOAP als auch von RESTful stellt der webPDF-Server insgesamt sechs Webservices zur Verfügung. Mit diesen kann man die PDF-Funktionen nutzen, die webPDF bereithält. Mehr zu den PDF-Webservices.

Die Webservices ermöglichen konkret folgende Bearbeitungsfunktionen:

1. Dateikonvertierung in das PDF-Format
2. Digitales Signieren
3. Konvertierung in PDF/A und Validierung bestehender PDF/A-Dokumente
4. Weitere Bearbeitung der PDF-Dokumente (Teilen, Sicherung, Grafikexport, Drucken)
5. URL Konvertierung: HTML-Inhalte werden per URL aufgerufen und in PDF-Dokumente verwandelt
6. Optische Texterkennung (OCR) von Grafik-Dokumenten und deren Umwandlung in PDF

Hinweis: Für jeden Webservice existieren individuelle Parameter. Mit den Parametern kann das Verhalten und die Ausführung der Webservices gesteuert werden. Die Parameter sind dabei identisch, egal ob Sie die SOAP oder RESTful-Webservices verwenden.