REST versus SOAP: Den passenden Webservice auswählen

Überblick über Webservices

Ein Webservice ist im weitesten Sinne eine Kommunikationsmethode zwischen zwei Anwendungen oder elektronischen Geräten über das World Wide Web (WWW). Webservices gibt es in zwei unterschiedlichen Arten: Als Simple Object Access Protocol (SOAP) und als Representational State Transfer (REST).

SOAP legt eine Standard-Kommunikationsprotokoll-Spezifikation (Regelwerk) für den XML-basierten Nachrichtenaustausch fest. SOAP verwendet verschiedene Transportprotokolle wie HTTP und SMTP. Das Standardprotokoll HTTP erleichtert es dem SOAP-Modell, ohne Änderungen am SOAP-Protokoll über Firewalls und Proxies zu tunneln. SOAP kann manchmal langsamer als Middlewaretechnologien wie CORBA oder ICE sein, da es ein ausführliches XML-Format hat.

REST beschreibt eine Reihe von Architekturprinzipien, mit denen Daten über eine standardisierte Schnittstelle (zum Beispiel HTTP) übertragen werden können. REST enthält keine zusätzliche Messaging-Schicht und konzentriert sich auf Designregeln für die Erstellung von stateless (zustandslosen) Services. Ein Client kann über die eindeutige URI auf die Ressource zugreifen und erhält eine Repräsentation der Ressource zurück. Mit jeder neuen Ressourcen-Repräsentation transferiert der Client seinen Zustand (state). Beim Zugriff auf RESTful-Ressourcen mit dem HTTP-Protokoll dient die URL der Ressource als Ressourcen-Identifikator und GET, PUT, DELETE, POST und HEAD sind die Standard-HTTP-Operationen, die auf dieser Ressource ausgeführt werden.

REST versus SOAP

Zwischen SOAP und RESTful Webservices gibt es erhebliche Unterschiede. Die nachstehenden Punkte stellen die Merkmale der einzelnen Webservices vor, die auf meinen persönlichen Erfahrungen beruhen.

REST

• RESTful Webservices sind stateless (zustandslos). Sie können diese Bedingung testen, indem Sie den Server neu starten und prüfen, ob Interaktionen weiter vorhanden sind.
• Für die meisten Server bieten RESTful Webservices eine gute Caching-Infrastruktur über eine HTTP-GET-Methode. Dies kann die Performance verbessern, wenn die Information, die der Service zurückgibt, nicht häufig geändert wird und nicht dynamisch ist.
• Service-Produzenten und -Konsumenten müssen den Kontext und die Inhalte, die weitergegeben werden, verstehen, weil es kein einheitliches Regelwerk zur Beschreibung der REST-Webservices-Schnittstelle gibt.
• REST ist nützlich für Geräte mit eingeschränktem Profil wie zum Beispiel für Mobilgeräte, bei denen der Overhead zusätzlicher Parametern geringer ist (zum Beispiel Header).
• REST-Services lassen sich leicht in bestehende Websites integrieren und werden mit XML dargestellt, so dass die HTML-Seiten leicht das Gleiche konsumieren können. Es besteht wenig Bedarf, die bestehende Site-Architektur zu überarbeiten. Damit sind Entwickler produktiver, weil sie nicht alles von Grund auf neu schreiben, sondern nur die vorhandene Funktionalität ergänzen müssen.
• Eine REST-basierte Implementierung ist im Vergleich zu SOAP einfach.

SOAP

• Die Web Services Description Language (WSDL) beschreibt ein gemeinsames Regelwerk zur Definition von Nachrichten, Bindungen, Operationen und Speicherorten des Service. WSDL kann man sich ähnlich wie einen Vertrag vorstellen, der die Schnittstelle beschreibt, die der Dienst anbietet.
• SOAP erfordert weniger Installationscode als das REST-Servicedesign (zum Beispiel Transaktionen, Sicherheit, Koordination, Adressierung und Vertrauen). Die meisten Anwendungen in der Praxis sind nicht einfach und unterstützen komplexe Operationen, bei denen es darauf ankommt, den Gesprächszustand und die Kontextinformationen aufrechtzuerhalten. Mit dem SOAP-Ansatz müssen Entwickler keinen Installationscode in die Anwendungsschicht schreiben.
• SOAP Webservices, wie zum Beispiel JAX-WS, sind für die asynchrone Verarbeitung und Aufrufe nützlich.
• SOAP unterstützt verschiedene Protokolle und Technologien, darunter WSDL, XSDs und WS-Addressing.

Die Nutzung eines Webservice über die Stored Procedure einer Datenbank ermöglicht es dem User, eine Datenbank mit Informationen aus verschiedenen Quellen immer sofort zu aktualisieren. Benutzer können auch einen Job in regelmäßigen Abständen implementieren, um die Daten regelmäßig in der Datenbank zu aktualisieren.

REST oder SOAP: Was eignet sich besser?

Befürworter von REST oder SOAP können recht leidenschaftlich für ihre bevorzugte Webservicearchitektur eintreten. Sowohl SOAP- als auch RESTful-Architekturen haben sich als zuverlässig, erfolgreich und skalierbar erwiesen. Die Entscheidung für REST oder SOAP hat daher weniger mit ihrer Effizienz zu tun, als vielmehr damit, wie sich beide Ansätze in die Softwareentwicklungskultur und die Projektanforderungen eines Unternehmens einfügen.

Sowohl SOAP- als auch RESTful-Webservices haben bewiesen, dass sie mit ihren Fähigkeiten die Anforderungen der größten Unternehmen der Welt erfüllen können. Gleichzeitig sind sie in der Lage, die kleinsten Internet-of-Things-Geräte oder eingebetteten Anwendungen in der Produktion zu bedienen.

Bei der Entscheidung zwischen REST und SOAP gibt es zwei Schlüsselthemen, die berücksichtigt werden müssen:

1. Die Typen von Clients, die unterstützt werden. Beispielsweise bieten REST-Dienste eine effektive Möglichkeit zur Interaktion mit leichtgewichtigen Clients wie zum Beispiel Smartphones.
2. Wie unterschiedlich flexibel und standardisiert etwas ist, wird entweder innerhalb der Unternehmenskultur abgelehnt oder akzeptiert.

Wenn Sie diese Faktoren im Hinterkopf behalten, können Sie Unternehmen dabei unterstützen, sich zwischen SOAP- und RESTful-Webservices zu entscheiden.

Häufig auftretende Probleme bei Webservices und -lösungen

Manchmal wird die Prozedur selbst dann nicht kompiliert, wenn man alles, was in der Stored Procedure zum Aufruf des Webservice erwartet wird, getan hat. Im Folgenden finden Sie eine Kompilierung von Laufzeitfehlern, die bei der Ausführung von Stored Procedures auftreten, um einen Webservice und seine -lösungen aufzurufen.

Problem 1: Die Fehlermeldung „ORA-25293: HTTP request failed“ beim Kompilieren der Prozedur.

Lösung: Führen Sie die folgenden Schritte aus, um diesen Fehler zu beheben.

• Melden Sie sich über den sys-Benutzer als sysdba an.
• Schauen Sie sich die Privilegien für das ausgewählte Schema an, um das Paket utl_HTTP zu verwenden. Verwenden Sie den Befehl wie folgt:
  • select grantee, table_name, privilege
    from dba_tab_privs
    where table_name = 'UTL_HTTP';
• Das Privileg wird standardmäßig allen öffentlichen Nutzern zur Verfügung gestellt.
• Führen Sie revoke execute grant on utl_http from public und stellen Sie es explizit dem spezifischen Schema zur Verfügung, von dem der Webservice aufgerufen werden muss.
  • revoke execute on utl_http from public;
  • grant execute on utl_http to BTFT2;
  • select grantee, table_name, privilege
    from dba_tab_privs
    where table_name =  'UTL_HTTP';

Problem 2: Wenn die Stored Procedure, die den Webservice aufruft, während des Aufrufs des Webservice „Network access denied“ zurückgibt.

Lösung: Fügen Sie die Webservice-URL zur Zugriffskontrollliste hinzu, indem Sie die folgenden Schritte ausführen.

• Melden Sie sich über sys als sysdba an.
• Führen Sie die folgende Prozedur aus, um eine ACL zu erzeugen.
  • BEGIN
    DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
         acl          => '<Name der ACL-Datei>.xml',
         description  => 'Berechtigungen für den Zugriff auf die Webservice-URL',
         principal    => '<Schema-Name>',
         is_grant    => TRUE,
         privilege    => 'connect');
    COMMIT;        
    END;        
    /
• Legen Sie eine Rolle an, und genehmigen Sie dann die Verbindung zu dieser Rolle auf der ACL, indem Sie die folgenden Schritte ausführen:
• • BEGIN
    DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
         acl          => '<Name der ACL-Datei>.xml',
         description  => 'Berechtigungen für den Zugriff auf die Webservice-URL',
         principal    => '<Schema-Name>',
         is_grant    => TRUE,
         privilege    => 'connect');
    COMMIT;         
    END;         
    /

• Weisen Sie der ACL die Hostnamen zu, um alle zugehörigen Links im Host zu öffnen.
  • BEGIN
    DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL (
         acl          => '<Name der ACL-Datei>.xml',              
    host         => '*.<Hostname der Webservice-URL>');
    COMMIT; 
    END; 
    /

oder

• BEGIN
  DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL (
        acl          => '<Name der ACL-Datei>.xml',              
  host         => '<ip>’);
  COMMIT;  
  END;
• Bestätigen Sie, dass die Domäne mit dem ACL_UTILITY Paket in die ACL aufgenommen wurde.
  • SELECT * FROM
    TABLE(DBMS_NETWORK_ACL_UTILITY.DOMAINS 
    ('www.ajax.googleapis.com'));
  • selectacl , host , lower_port , upper_port from DBA_NETWORK_ACLS;
  • selectacl , principal , privilege , is_grant from BA_NETWORK_ACL_PRIVILEGES;

Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+, Xing und Facebook!