REST versus SOAP: den passenden Webservice wählen

Einstieg in die 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 dem SOAP-Modell das Tunneln über Firewalls und Proxies hinweg, ohne dass Änderungen am SOAP-Protokoll erforderlich sind. SOAP kann aufgrund seines ausführlichen XML-Formats manchmal langsamer sein als Middleware-Technologien wie CORBA oder ICE.

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 zustandslosen (stateless) 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 Ressourcenkennung, und GET, PUT, DELETE, POST und HEAD sind die Standard-HTTP-Operationen, die mit dieser Ressource durchgeführt werden.

REST und SOAP im Vergleich

Zwischen SOAP- und RESTful-Webservices gibt es erhebliche Unterschiede. Die nachstehenden Punkte stellen die Merkmale der einzelnen Webservices vor:

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-Webservicesschnittstelle 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 sie problemlos nutzen können. Es besteht wenig Bedarf, die bestehende Website-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 Services. 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 realen Anwendungen sind nicht einfach und unterstützen komplexe Vorgänge, die die Aufrechterhaltung von Konversationsstatus und Kontextinformationen erfordern. Mit dem SOAP-Ansatz müssen die Entwickler keinen Code in die Anwendungsschicht einfügen.
• 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 Webdienstes über eine gespeicherte Datenbankprozedur ermöglicht es den Benutzern, eine Datenbank sofort mit Informationen aus verschiedenen Quellen zu aktualisieren. Die Benutzer können auch einen Auftrag in regelmäßigen Abständen planen, um die Daten in der Datenbank regelmäßig 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 (IoT) 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 folgende 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 Webservices „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:
  • create role role1; 
  • BEGIN
    DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
         acl          => '<Name der ACL-Datei>.xml',
         principal    => 'role1',
         is_grant    => TRUE,
         privilege    => 'connect';
         position    => null;
    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;