REST im Vergleich zu SOAP – Moderne Anwendungen erstellen

Entwickler haben bei der Erstellung moderner Anwendungen viele Möglichkeiten. Statische oder dynamische Sprachen, etablierte Akteure wie Java oder relative Neulinge wie Golang, monolithische All-in-One-Frameworks oder modularisierte Bibliotheken und sogar die Tatsache, dass Ihr gesamter Stack auf Javascript läuft, sind nur die Spitze des Eisbergs. Zu dieser Liste kommt noch eine wichtige Entscheidung hinzu, die Entwickler treffen müssen: REST oder SOAP.

REST und SOAP sind, einfach ausgedrückt, Methoden der Kommunikation zwischen Anwendungen. Obwohl das Ziel dasselbe ist, können REST und SOAP nicht direkt miteinander verglichen werden, da REST eine Reihe von Richtlinien ist, die Entwickler von Projekt zu Projekt unterschiedlich umsetzen können, während SOAP ein gut definiertes und standardisiertes Protokoll für den Datenaustausch ist. Dennoch lässt sich ein Vergleich anstellen, der die Vor- und Nachteile des einen gegenüber dem anderen aufzeigt. Beide sind in der Branche noch immer weit verbreitet, und wir hoffen, dass wir Ihnen aufzeigen können, warum und wann Sie das eine dem anderen vorziehen sollten.

Representational State Transfer (REST) ist ein architektonisches Muster, das häufig bei der Entwicklung moderner webbasierter Anwendungen verwendet wird, z. B. bei Websites, mobilen Anwendungen, Spielen und mehr. Die Entwicklung einer REST-basierten API ermöglicht es Ihnen, die Funktionalität Ihres Webdienstes über HTTP offenzulegen und über das Web mit ihm zu interagieren. Unter Verwendung von HTTP-Verben wie GET und POST weist der Client die API an, Ressourcen abzurufen oder zu erstellen.

RESTful APIs haben aufgrund ihrer Interoperabilität und Flexibilität im Web stark an Popularität gewonnen. Webservices, die mit dieser Architektur erstellt wurden, können sich unabhängig von den Anwendungen, die sie nutzen, weiterentwickeln. REST-basierte APIs verfügen nicht über ein genau definiertes Sicherheitsprotokoll – JSON-Web-Token (JWTs) sind jedoch die gängigste Methode zur Authentifizierung und Autorisierung von Anfragen.

Vorteile

• Zustandslos – Jeder Aufruf des Webdienstes verfügt über alle Informationen, die er zur Bearbeitung der Anfrage benötigt, und ist nicht auf die Speicherung von Client-Server-Kontext angewiesen.
• Flexibel – RESTful APIs können Daten in vielen verschiedenen Formaten akzeptieren und bereitstellen, darunter JSON, XML, Atom und andere. JSON ist das bei weitem beliebteste Datenformat, das in REST-basierten APIs verwendet wird.
• Cachefähig – Antworten sind cachefähig, was die Leistung des Webdienstes erheblich verbessern kann, da unnötige Aufrufe an das Backend vermieden werden.

Nachteile

• Standards – Es gibt keinen definierten Standard für die Erstellung von REST-basierten APIs. Es gibt viele großartige Ressourcen und Leitfäden wie die White House RESTful API Standards und das REST API Tutorial, aber es gibt viele Permutationen von REST-basierten APIs.
• HTTP – RESTful-Anwendungen beschränken sich auf das HTTP-Protokoll.

Simple Object Access Protocol (SOAP) hingegen ist ein Protokoll für den Datenaustausch. Seine Stärken liegen darin, dass es eine Reihe von Regeln und Standards hat, die für eine erfolgreiche Client/Server-Interaktion eingehalten werden müssen. SOAP-Anfragen werden über Umschläge übermittelt, die alle für die Verarbeitung der Anfrage erforderlichen Informationen enthalten müssen.

Ein SOAP-Anfrageumschlag besteht im Allgemeinen aus einem optionalen Header- und einem erforderlichen Body-Attribut. Das Header-Attribut wird für Informationen wie Sicherheitsnachweise und andere Metadaten verwendet, während das Body-Attribut für die eigentlichen Daten und für auftretende Fehler verwendet wird. Dies ist eine vereinfachte Beschreibung dessen, wie SOAP den Datenaustausch handhabt. Wenn Sie tiefergehende Informationen wünschen, sehen Sie sich die W3C-Spezifikation an, und wenn Sie gleich einen SOAP-Webdienst schreiben möchten, versuchen Sie es mit einem leicht verständlichen Tutorial.

Vorteile

• WSDL  – Die Web Services Description Language (WSDL) beschreibt die Methoden des Webdienstes, den Zugriff und andere Parameter, sodass Sie aus einer Hand lernen können, wie Sie die API nutzen können.
• Erweiterbarkeit  – WS-* Erweiterungen wie WS-Security, WS-Addressing, WS-Federation und andere können die Möglichkeiten der Anwendung erheblich erweitern.
• Protokollneutral – zugänglich über HTTP, SMTP, TCP und andere Protokolle auf Anwendungsebene.

Nachteile

• XML-Infoset – SOAP verwendet XML für die Übertragung von Payload-Daten, deren Serialisierung erheblich länger dauern kann, was zu Leistungsproblemen führt.
• Komplexe Syntax – SOAP arbeitet ausschließlich mit XML und das Lesen der Datenumschläge kann schwierig und zeitaufwändig sein.

RESTful APIs sind überall zu finden. Von einseitigen Anwendungen bis hin zum Internet der Dinge (IoT) sind Dienste, die auf REST-basierten APIs basieren, die Regel. Neben den oben genannten technischen Vorteilen eignen sich REST-basierte APIs für viele Unternehmen, weil sie im Allgemeinen einfacher zu verstehen und zu entwickeln sind. REST ist eine gute Wahl für Startups, mobile Anwendungen und Entwickler, die moderne Einzelseitenanwendungen (SPA) erstellen.

Viele Unternehmen sind darauf ausgerichtet, eine RESTful API anzubieten, die ein einzelnes Problem löst und sich nahtlos in jede Anwendung integrieren lässt. Auth0 ist ein gutes Beispiel dafür. Andere häufige Anwendungsfälle für REST sind Unternehmen, die ihren Datenbestand offenlegen und es Drittanbietern ermöglichen, Produkte auf der offengelegten API aufzubauen, wie z. B. die Falcon App, die auf der RESTful API von Twitter basiert.

Webdienste, die SOAP verwenden, sind in Unternehmensumgebungen weit verbreitet. Große Unternehmensumgebungen wie das Bankwesen und das Gesundheitswesen profitieren am meisten von der Verwendung von SOAP, da es ihnen mehr Flexibilität und Kontrolle über die Client/Server-Interaktionen bietet. Der Ausdruck komplexer Methoden ist mit SOAP generell einfacher, ebenso wie ACID-konforme Transaktionen.

SOAP ist besser für größere Unternehmen geeignet, was aber nicht bedeutet, dass es nicht auch für kleinere Unternehmen verwendet werden kann oder sollte. Der einzige Nachteil ist, dass die Entwicklung einer SOAP-Anwendung in der Regel länger dauert. Wenn Sie also nur mit einer Idee experimentieren, kann es sein, dass Sie angesichts der Komplexität des Codes im Vergleich zum tatsächlichen Versandcode überfordert sind. Ein gängiger Prüfstein in der Debatte zwischen REST und SOAP lautet: „Wenn Sie keinen konkreten Grund für die Erstellung Ihres Webdienstes mit SOAP finden können, verwenden Sie REST.“

REST-APIs werden in der Regel mit JSON-Web-Token (JWT) authentifiziert. Wenn ein API-Endpunkt geschützt werden muss, besteht die Strategie darin, vom Client zu verlangen, dass er bei einer Anfrage an die API einen Authorisierungs-Header einfügt, der ein Token enthält, das die Identität des Anfragenden bestätigt. Der Server überprüft dann, ob das Token gültig ist, und verarbeitet die Anfrage, wenn dies der Fall ist.

Die Verwendung einer Token-basierten Authentifizierung bietet viele Vorteile, die Sie hier nachlesen können. REST-APIs sind nicht auf die Token-basierte Authentifizierung beschränkt. Sie können eine Cookie-/Session-basierte Authentifizierung verwenden oder sogar Ihren eigenen Mechanismus für die Authentifizierung entwickeln.

Schauen wir uns ein Beispiel dafür an, wie Sie Ihre RESTful-API mit JWT schützen können. Sie haben eine mobile Anwendung entwickelt, die ein motivierendes Zitat des Tages anzeigt. Das tägliche Zitat wird über eine GET-Anfrage an Ihre RESTful API unter /api/v1/quote abgerufen. Das Feedback, das Sie erhalten haben, ist großartig und Ihre Benutzer sind sehr engagiert. Sie möchten ihnen die Möglichkeit geben, ihre eigenen Zitate an die App zu übermitteln.

Es wird ein neuer RESTful-Endpunkt erstellt, sodass, wenn eine POST-Anfrage an /api/v1/quote gesendet wird, die die erforderlichen Daten im Body enthält, das eingereichte Angebot in der Datenbank für Ihre Überprüfung gespeichert wird. Sie wollen aber nicht, dass Ihnen jeder ein Zitat schicken kann. Dies sollte nur registrierten Benutzern möglich sein. Die Implementierung der API sieht folgendermaßen aus:

...

routes.post('/api/v1/quote', function(req, res){
    // getToken ist eine Hilfsfunktion, die nach einem Autorisierungsschlüssel
    // in der Kopfzeile sucht, der den Wert 'Bearer {token}' enthält.
    // Sie entfernt dann das Schlüsselwort Bearer und liefert nur den Wert {token}
    var token = getToken(req.headers.authorization);
    var quote = req.body.quote;

    jwt.verify(token, 'secret', function(err, decoded){
        if(err){
            res.json(err) // Fehlerdetails zurückgeben (Return error details)
        } else {
            // Save the quote to a database
            res.json({'message':'Quote Successfully Submitted. Thank you!'}); 
        }
    });
});

...

Wenn ein Benutzer in der obigen Implementierung eine POST-Anfrage an den Endpunkt /api/v1/quote sendet, extrahieren wir seinen JWT und speichern ihn in einer Variablen namens token. Wenn der Autorisierungs-Header nicht vorhanden ist, brechen wir die weitere Ausführung einfach ab, da wir davon ausgehen können, dass der Benutzer nicht authentifiziert ist. Wenn wir ein Token erhalten, überprüfen wir, ob es gültig ist. Das Token wird anhand eines Geheimnisses überprüft, mit dem es ursprünglich signiert wurde. Außerdem prüfen wir, ob das Token abgelaufen ist. Das decodierte Objekt kann zusätzliche Daten wie z. B. Benutzerrechte enthalten, die bei der Erstellung des Token hinzugefügt werden können, aber für unsere Demo haben wir es einfach gehalten.

POST an API mit gültigem JWT

POST an API ohne JWT

Wenn alles klappt und kein err zurückgegeben wird, wissen wir, dass der Benutzer authentifiziert ist. Dann speichern wir sein Zitat in der Datenbank und senden ihm eine nette Nachricht, in der wir ihm für die Nutzung unserer App danken. In diesem Beispiel haben wir die Token-Verifizierung innerhalb der Endpunkt-Implementierung durchgeführt. In einem realen Szenario würde die Token-Verifizierung vorzugsweise über eine Middleware erfolgen, die weiter oben im Call-Stack angesiedelt ist.

Auth0 kann die Generierung von JWTs als Teil des Authentifizierungsprozesses problemlos übernehmen. Sobald sich ein Benutzer erfolgreich angemeldet hat, gibt Auth0 ein JWT zurück, das Sie im lokalen Speicher oder in einem Cookie ablegen. Jedes Mal, wenn eine Anfrage an die API gesendet wird, fügen Sie das Token in der Kopfzeile unter einem Autorisierungsschlüssel an. Auf der Serverseite müssen Sie dieses Token validieren, was, wie wir oben gesehen haben, eine einfache Aufgabe ist, wenn Sie eines der vielen Auth0 SDKs verwenden.

SOAP ist genauso flexibel wie REST, wenn es um den Schutz und die Authentifizierung eines Webdienstes geht. WS-Security ist die Schlüsselerweiterung, die viele Authentifizierungsmodelle unterstützt, darunter: einfache Benutzername/Passwort-Anmeldeinformationen, SAML, OAuth und mehr.

Eine gängige Methode zur Authentifizierung von SOAP-APIs ist SAML Single Sign-on (SSO). SAML erleichtert den Austausch von Authentifizierungs- und Autorisierungsdaten zwischen Anwendungen. Ein SAML-Verbund besteht aus drei Teilen: dem Benutzer, einem Identitätsanbieter und einem Dienstanbieter. Der Benutzer stellt eine Anfrage vom Dienstanbieter an einen Identitätsanbieter und wenn die Anfrage erfolgreich ist, wird der Benutzer authentifiziert und kann auf die Anwendung zugreifen.

Die Implementierung von SAML SSO kann eine entmutigende, schwierige und zeitintensive Aufgabe sein. Auth0 kann helfen! Schauen wir uns an, wie schnell wir SAML SSO mit SSOCircle einrichten können. Auth0 wird der Dienstanbieter sein, während SSOCircle der Identitätsanbieter ist, d.h. sobald ein Benutzer versucht, sich anzumelden, wird er zu SSOCircle weitergeleitet, um seine Identität zu überprüfen.

Nachdem wir ein SSOCircle-Konto erstellt haben, können wir nun die öffentlichen Metadaten für SSOCircle abrufen. Diese können wir unter https://idp.ssocircle.com/ abrufen. Von hier aus wollen wir drei Attribute abrufen, das KeyDescriptor Signing X509 Certificate, SingleSignOnService Redirect Location und das SingleLogoutService Redirect Location.

Wir beginnen mit der Erstellung einer neuen .pem-Datei, um das Zertifikat zu speichern, indem wir eine neue Datei erstellen und das X509-Zertifikat kopieren. Außerdem müssen wir die Begrenzungszeichen für Beginn und Ende des Zertifikats hinzufügen, wie unten gezeigt.

-----BEGINN ZERTIFIKAT-----
MIIDATCCAemgAwIBAgICCpgwDQYJKoZIhvcNAQEFBQAwLjELMAkGA1UEBhMCREUx
EjAQBgNVBAoTCVNTT0NpcmNsZTELMAkGA1UEAxMCQ0EwHhcNMTEwNTE3MTkzNDEx
WhcNMjEwODE3MTkzNDExWjAuMQswCQYDVQQGEwJERTESMBAGA1UEChMJU1NPQ2ly
Y2xlMQswCQYDVQQDEwJDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
ALm1xZq5goTh7NmdzZsZUJed9+7XauwuaNuGyZpIGRo4FsP1YPgs+40mYAoa9rDj
CEekixkfSI6nBUMdHuRIMHogyu/OVxskrL91SLO5m5u9JhgIhO/s9pnmnrnNUILf
RccE4+AEO1xsBQ/x1sY2zDZk+71Pfvifc9vVxedHpNAumbe1nb+CofUtAbF6PkHv
g3pqCoMPmC7m4NAr9h+zq3ekeWf8j5SOicupet9XhsO6zUr0Wga/Zs6J0khhYmFy
zpqoP2rLJ4a/9qduSGslOWsed6kD+zvhLMAUVcw3goli4VhepNzU5iGL9QdVj7m4
YQRMofBRYyL7tBWO6jzLpFcCAwEAAaMpMCcwFAYJYIZIAYb4QgEBAQH/BAQDAgD/
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBAKmOo8un97VFxNgo
iAzpU5fugKdAFFnKHTvUzDLQ81O455OyT6tcAsXHz6sy2c6GozqDV7xrXSqnues8
p9/w0KzVY9/YuxB90uiSJVh0zMxS+NwyfG1Od5Brloh9eBM4YulUI3V2ustcck17
2G4X4/QSK8uo0bjELUzSNAGj7uypsKKXjX++enfAJzLSsqk3Y8Tmon4R6GYBj4mo
1nL6ujeXqB/kH44XnEmU7ojyIC1kawFRdY4GDFIq3HOBFNzlNbJVL+jKdgTQJTET
rNTDjxXmxwpZ90+lPbEaLQeElwAQi7pMtcqD/f8Dqaifk9ZvpCB7NC+oLM5ej9nK
TawsVqs=
-----ENDE ZERTIFIKAT-----

Speichern Sie diese Datei unter dem Namen SSOCircle.pem. Navigieren Sie zum Auth0 Dashboard und erstellen Sie eine neue SAMLP Identitätsanbieter-Verbindung, indem Sie zu Verbindungen (Connections) und dann zum Untermenü Unternehmen (Enterprise) navigieren und auf das Symbol + im Abschnitt SAMLP Identitätsanbieter (SAMLP Identity Provider) klicken. Es gibt viele Einstellungen, die wir hier konfigurieren können, aber für unsere Demo legen wir zunächst einen Verbindungsnamen fest, den Sie frei wählen können. Für diese Demo überspringen wir die E-Mail-Domänen, aber im Abschnitt E-Mail-Domänen (email domains) legen Sie fest, welche Domänen automatisch mit Single Sign-on funktionieren sollen; in der Regel ist dies Ihre Unternehmensdomäne.

Die Anmelde- und Abmelde-URLs haben wir aus den öffentlichen SSOCircle-Metadaten erhalten, also fügen wir sie hier ein. Der letzte Teil der Konfiguration ist das Hochladen des .pem Zertifikats, das wir zuvor erstellt haben. Wenn diese Einstellungen konfiguriert sind, können wir den Rest ignorieren und einfach auf Speichern (save) klicken.

Nachdem Sie die Einstellungen gespeichert haben, werden Sie aufgefordert, fortzufahren und die Metadaten für Ihre Verbindung abzurufen. Sie sollten wie folgt aussehen:

<EntityDescriptor entityID='urn:auth0:{ACCOUNT_NAME}:{CONNECTION_NAME}' xmlns='urn:oasis:names:tc:SAML:2.0:metadata'>
  <SPSSODescriptor WantAssertionsSigned='true' protocolSupportEnumeration='urn:oasis:names:tc:SAML:2.0:protocol'>

    <SingleLogoutService Binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect' Location='https://{ACCOUNT_NAME}.auth0.com/samlp/logout'/>
    <SingleLogoutService Binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' Location='https://{ACCOUNT_NAME}.auth0.com/samlp/logout'/>
    <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
    <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
    <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
    <AssertionConsumerService Binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' Location='https://{ACCOUNT_NAME}.auth0.com/login/callback?connection={CONNECTION_NAME}' index='0' isDefault='true'/>
  </SPSSODescriptor>
</EntityDescriptor>

Dies sind Ihre Verbindungs-Metadaten, die Sie für die Registrierung eines neuen Dienstanbieters auf der Seite von SSOCircles verwenden werden. Gehen Sie zu SSOCircle und navigieren Sie zum Abschnitt Metadaten verwalten (Manage Metadata). Klicken Sie dort auf die Schaltfläche Neuen Dienstanbieter hinzufügen (Add New Service Provider). Geben Sie den vollständig qualifizierten Domainnamen (FQDN) ein, in unserem Fall auth0.com, wählen Sie EmailAddress im Abschnitt Attribute, die bei der Assertion gesendet werden (attributes sent in assertion) und fügen Sie schließlich die XML-Metadaten in das Textfeld ein. Klicken Sie auf Absenden (submit). Der Auth0-Dienstanbieter wird registriert.

Um zu testen, ob die Verbindung erfolgreich war, klicken Sie auf die Schaltfläche Verwalten (manage) unter dem Abschnitt SAMLP Identitätsanbieter (SAMLP Identity Provider ) und dann auf Versuchen (das ist das Play-Symbol). Wenn alles geklappt hat, sollten Sie einen Bildschirm wie den unten abgebildeten sehen. Das ist alles! Jetzt haben Sie SAML Single Sign-on integriert, wobei Auth0 als Dienstanbieter und SSOCircle als Identitätsanbieter fungiert. Eine ausführlichere Anleitung zur Implementierung eines SAML-Verbunds finden Sie in den Dokumenten.

Ganz gleich, ob Sie eine mobile App entwickeln, die RESTful-Dienste nutzt, oder eine SOAP-Anwendung für Ihr Unternehmen: Mit Auth0 sind Sie auf der sicheren Seite, wenn es um die Authentifizierung geht.

Die JWT-Authentifizierung ist das A und O von Auth0. Mit einer umfangreichen Authentifizierungsbibliothek sowie SDKs für viele Programmiersprachen und Frameworks können Sie die Authentifizierung in wenigen Minuten einrichten. Die Unterstützung von über 30 sozialen Verbindungen, darunter Facebook, Twitter und Google, sowie die Möglichkeit, eine vorhandene Benutzerdatenbank zu verwenden, machen den Wechsel zu Auth0 zum Kinderspiel.

Auth0 kann sowohl als Dienstanbieter als auch als Identitätsanbieter in einem SAML-basierten Verbund fungieren. Anwendungen wie Salesforce oder Box können Auth0 als Identitätsanbieter nutzen, um Benutzern die Anmeldung bei solchen Diensten über Auth0 zu ermöglichen. Wenn Auth0 als Dienstanbieter fungiert, sendet Auth0 eine Autorisierungsanfrage an einen Identitätsanbieter wie SSOCircle, OneLogin oder einen anderen SAML-kompatiblen Identitätsanbieter.