SOAP vs. REST APIs: Das sind die Unterschiede

xDie Entscheidung zwischen REST und SOAP ist für Neulinge im Bereich der API-Erstellung alles andere als einfach, denn SOAP und REST verfolgen bei der Datenübertragung für APIs unterschiedliche Ansätze.

Möchten Sie Ihre App mit Instagram und Facebook verbinden, um Bilder mit bestimmten Hashtags erneut zu veröffentlichen oder automatisch Beiträge zu erstellen? Oder möchten Sie YouTube-Videos auf Ihrer Website einbetten? All dies und mehr ist dank Programmierschnittstellen (APIs oder Application Programming Interfaces) möglich.

APIs wie die Instagram API, die Facebook API oder die YouTube API ermöglichen die sichere und standardisierte Verbindung zwischen verschiedenen Softwareanwendungen. Das heißt: Eine Anwendung kann Funktionen oder Daten aus einer anderen Software extrahieren und zur Verbesserung der eigenen Funktionen oder des eigenen Nutzererlebnisses (UX) einsetzen.

Wie aber erstellen, verarbeiten und beantworten Anwendungen diese Anforderungen effektiv? Das hängt im Einzelnen davon ab, wie die API erstellt ist. Sehen wir uns dies anhand der zwei beliebtesten Methoden an: SOAP und REST. Anschließend vergleichen wir die Unterschiede im Detail.

Was ist SOAP?

SOAP steht für „Simple Object Access Protocol“, eine äußerst strikte und sichere Möglichkeit zum Erstellen von APIs. Daten werden dabei in XML kodiert.

Was ist REST?

REST steht für „Representational State Transfer“. Mit REST lassen sich APIs einfacher und flexibler erstellen als mit SOAP. REST-APIs können Daten in verschiedenen Formaten übertragen, etwa XML, Nur-Text, HTML oder JSON.

Beide API-Formate verwenden nicht nur menschen- und maschinenlesbare Daten, sondern auch oft HTTP-Protokolle. Doch es gibt auch zahlreiche Unterschiede zwischen REST und SOAP.

In der folgenden Tabelle finden Sie eine Übersicht der Unterschiede:

Jetzt, da Sie die allgemeinen Merkmale von SOAP und REST kennengelernt haben, wollen wir uns näher mit den Unterschieden bei den Services und der Sicherheit befassen und uns einige Beispiele ansehen.

• SOAP vs. REST: Services
• SOAP vs. REST: Sicherheit
• SOAP vs. REST: Beispiele

SOAP vs. REST: Services

Um die Unterscheide von SOAP- und REST-APIs überhaupt vergleichen zu können, müssen wir zunächst verstehen, was die beiden API-Typen jeweils genau tun.

SOAP Services

SOAP ist ein Standard-Kommunikationsprotokoll, das XML-Technologien verwendet, um ein umfangreiches Messaging-Framework zu definieren. So können dann strukturierte Informationen in einer dezentralisierten und verteilten Umgebung ausgetauscht werden.

Mit SOAP können Anwendungen also auf verschiedenen Betriebssystemen ausgeführt werden und über unterschiedliche Technologien und Programmiersprachen miteinander kommunizieren.

Mit SOAP-APIs lassen sich Datensätze wie Passwörter, Konten, Leads und benutzerdefinierte Objekte von einem Server erstellen, abrufen, aktualisieren oder löschen.

REST Services

REST hingegen ist kein Protokoll, sondern ein architektonischer Stil. Es steht wie gesagt für „Representational State Transfer“. Das heißt: Wenn ein Client eine Ressource über eine REST-API anfordert, übermittelt der Server den aktuellen Zustand der Ressource in einer standardisierten Darstellung zurück.

REST-APIs erhalten also Anforderungen für eine Ressource und geben alle relevanten Informationen über diese Ressource in einem Format zurück, dass von Clients einfach interpretiert werden kann.

Neben der Anforderung von Ressourcen können Clients mit REST-APIs neue Elemente auf einem Server mittels HTTP-Methoden ändern oder sogar hinzufügen.

SOAP vs. REST: Sicherheit

Nachdem wir die Services von SOAP- und REST-APIs kennengelernt haben, vergleichen wir nun die Sicherheitsmaßnahmen und -protokolle.

SOAP Sicherheit

Da es sich bei SOAP um ein Messaging-Protokoll handelt, zielen die Sicherheitsmaßnahmen bei SOAP-APIs hauptsächlich darauf ab, den unbefugten Zugriff auf die gesendeten und empfangen Nachrichten (sowie die Nutzerinformationen in diesen Nachrichten) zu verhindern.

Die wichtigste Maßnahme gegen unbefugten Zugriff ist WS-Security. Dabei handelt es sich um eine Reihe von Prinzipien, die die Vertraulichkeits- und Authentifizierungsverfahren für den Nachrichtenaustausch mit SOAP regeln. Sicherheitsmaßnahmen, die mit WS-Security kompatibel sind, umfassen u. a. Passwörter, XML-Verschlüsselung und Sicherheitstoken.

WS-Security bietet weit mehr als herkömmliche Websicherheitsmaßnahmen wie HTTPS. Bei HTTPS werden Nachrichten nur während der Übertragung zwischen dem anfordernden Client und dem Server oder Webservice, der die angeforderten Daten enthält, gesichert. Bei WS-Security hingegen werden die Nachrichten über die HTTPS-Verbindung und manchmal sogar über die Transportschicht hinaus gesichert.

Das funktioniert so:

Eine SOAP-Nachricht enthält entweder die zu ihrer Sicherung erforderlichen Informationen oder Angaben dazu, woher sie diese Sicherungsinformationen beziehen kann. Zusätzlich enthält sie im Header Informationen zu den Protokollen und Verfahren, die zur Verarbeitung der angegebenen Sicherheit auf Nachrichtenebene erforderlich sind.

Wenn also ein Webservice-Endpunkt eine SOAP-Nachricht erhält, verifiziert er die Sicherheitsinformationen im Header und stellt so sicher, dass sie nicht manipuliert wurde. Daher spricht man bei SOAP von „Sicherheit auf Nachrichtenebene“.

SOAP unterstützt u. a. folgende WS-Spezifikationen:

• WS-Addressing
• WS-Policy
• WS-Security
• WS-Federation
• WS-ReliableMessaging
• WS-Coordination
• WS-AtomicTransaction
• WS-RemotePortlets

SOAP-APIs eignen sich somit perfekt für interne Datentransfers und andere Aufgaben, bei denen die Vertraulichkeit äußerst wichtig ist. Für einen öffentlichen Webservice, der für alle uneingeschränkt verfügbar ist, etwa das Abrufen von Wetterdaten, sind diese APIs jedoch unnötig. Wann REST- und wann SOAP-APIs eingesetzt werden, besprechen wir später in diesem Beitrag.

REST Sicherheit

REST-APIs unterstützen nur herkömmliche Web-Sicherheitsmechanismen wie HTTPS. Das heißt: Wenn eine Anwendung Nachrichten über eine REST-API mithilfe von HTTPS sendet und empfängt, ist sie nur für die HTTPS-Verbindung sicher. Sie ist nur während der Übertragungen zwischen Client und Service geschützt. Für öffentliche Webservices ist dies ausreichend, möglicherweise aber nicht für die Übertragung von vertraulichen Daten.

Da REST-APIs im Gegensatz zu SOAP nicht über integrierte Sicherheitskapazitäten oder -erweiterungen verfügen, hängt ihre Sicherheit vom Design der APIs ab. REST-APIs können so entwickelt werden, dass sie bestimmte Sicherheitsmechanismen enthalten. Dadurch wird sichergestellt, dass nur authentifizierte und befugte Nutzende Zugriff auf sie haben. Beliebte Authentifizierungsmethoden für REST-APIs sind die einfache HTTP-Authentifizierung, JSON-Webtoken, OAuth und API-Schlüssel.

REST-APIs sollten auch detaillierte Spezifikationen enthalten und alle Anforderungen ablehnen, die im HTTP-Header nicht die korrekte Deklaration enthalten oder anderweitig gegen die Spezifikationen verstoßen. So wird die zugrunde liegende Webanwendung auch dann vor inkorrekten und bösartigen Eingaben geschützt, nachdem der Client Zugriff erhalten hat.

SOAP vs. REST: Beispiele

Vergleichen wir nun einige Beispiele zu Anforderungen und Antworten bei SOAP- und REST-APIs. Die Beispiele basieren auf der QAComplete SOAP-API und der QAComplete REST-API. QAComplete von SmartBear ist ein umfassendes Testmanagement-Tool für Software.

SOAP Beispiel

QAComplete SOAP-Anforderungen sind HTTP POST-Anforderungen an die Endpunkt-URL eines Webservice. Client und Server tauschen Daten im XML-Format im Hauptteil der HTTP-Anforderungen und -Antworten aus.

Diese SOAP-API akzeptiert nur HTTP POST-Anforderungen, unterstützt aber auch verschiedene häufige Abläufe für alle Elementtypen, darunter Add, Delete, Load, LoadByCriteria und Update. Diese Abläufe werden statt der HTTP-Verben GET, PUT, PATCH und DELETE angezeigt.

Im nachstehenden Beispielcode wird angefragt, einen Fehler nach ID in einem Projekt in QAComplete mit der SOAP-API zu erhalten. Das Code-Snippet ist in XML geschrieben und verwendet die Operation „Bugs_Load“:

 
POST /psws/psws.asmx HTTP/1.1
Host: myteam.mysite.com
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 486 {Insert an appropriate value here}

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<Bugs_Load xmlns="http://www.pragmaticsw.com/">
<AuthenticationData>
<AppCode>agSP</AppCode>
<DeptId>7154</DeptId>
<ProjId>1032</ProjId>
<UserId>25315</UserId>
<PassCode>p@ssword</PassCode>
</AuthenticationData>
<BugId>5</BugId>
</Bugs_Load>
</soap12:Body>
</soap12:Envelope>

Die Antwort enthält einen HTTP-Statuscode und ein Bug-Objekt mit Informationen zum gewünschten Fehler. Sie ist in XML geschrieben. Im Beispiel unten gibt der HTTP-Statuscode 200 an, dass die Anfrage erfolgreich war, und zeigt Informationen zum Fehler in XML:

 
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 2244 {The server returns an appropriate value here}

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<Bugs_LoadResponse xmlns="http://www.pragmaticsw.com/">
<Bugs_LoadResult>
<CustomFields>
<string>0.9.19</string>
<string>1.0.24</string>
</CustomFields>
<CustomFieldNames>
<string>Found in build</string>
<string>Fixed in build</string>
</CustomFieldNames>
<BugId>13254</BugId>
<Title>Floating toolbar improvements</Title>
<StatusCode>Resolved</StatusCode>
<PriorityCode>2-Fix Soon</PriorityCode>
<HowFoundCode>Test-Ad hoc</HowFoundCode>
<ResolutionCode>Fixed</ResolutionCode>
<AssigneeUserId>27942</AssigneeUserId>
<OpenedBy>27568</OpenedBy>
<ClosedBy>27942</ClosedBy>
<ResolvedBy>27568</ResolvedBy>
<Description><![CDATA[The design of the floating toolbar needs improvement so that it’s clearer what the user needs to do.]]></Description>
<Resolution>Resolved by Susan McLaren on 24-Jun-2014 at 03:55 PM</Resolution>
<OwnerUserId>27572</OwnerUserId>
<TestCaseId>0</TestCaseId>
<FolderId>52359</FolderId>
<EstHrs>0.000</EstHrs>
<EstStart>2014-06-10T10:00:00</EstStart>
<EstFinish>2014-06-13T10:00:00</EstFinish>
<PctComplete>100</PctComplete>
<ActHrs>0.000</ActHrs>
<ActualStart>2014-06-17T00:00:00</ActualStart>
<ActFinish>2014-06-31T00:00:00</ActFinish>
<EstHrsRemaining>0.000</EstHrsRemaining>
<DateOpened>2014-05-26T15:54:21.093</DateOpened>
<DateResolved>2014-06-24T15:55:25</DateResolved>
<DateClosed>0001-01-01T00:00:00</DateClosed>
<DateUpdated>2014-06-31T05:54:22</DateUpdated>
<ProjId>17823</ProjId>
<DateCreated>2014-05-26T15:54:21.093</DateCreated>
<UpdateUserId>27534</UpdateUserId>
<OriginalId>0</OriginalId>
<ImportId>0</ImportId>
<AssignedToName>Doe, John</AssignedToName>
<OpenedByName>McLaren, Susan</OpenedByName>
<OpenedByEmail>susan@example.com</OpenedByEmail>
<OpenedByCompany>Edgar Solutions</OpenedByCompany>
<ResolvedByName>McLaren, Susan</ResolvedByName>
<UserName>Fry, Alex</UserName>
<OwnerName>Davis, Eugeny</OwnerName>
<NbrFiles>0</NbrFiles>
<NbrNotes>1</NbrNotes>
<NbrEvents>0</NbrEvents>
<NbrTasks>2</NbrTasks>
<FolderName>FamilyAlbum/Release 1.1/Iteration 1</FolderName>
</Bugs_LoadResult>
</Bugs_LoadResponse>
</soap12:Body>
</soap12:Envelope>

Hinweis: Diese SOAP-Nachricht enthält einen Envelope, Header und ein Body-Element, die alle jeweils erforderlich sind.

REST Beispiel

Bei REST-Anforderungen handelt es sich um HTTP-Anforderungen an die Endpunkt-URL der QAComplete REST-API im folgenden Format: http(s)://{Ihr Server}/rest-api/service/api/{Version}/{Ressource}. Diese API verwendet die HTTP-Methoden GET, POST, PUT, PATCH und DELETE.

Im nachstehenden Beispielcode wird angefragt, einen Fehler nach ID in einem Projekt in QAComplete mit der QAComplete REST-API zu erhalten. Das Code-Snippet ist in JSON geschrieben und verwendet die HTTP-Methode GET:

 
GET http://yourserver.com/rest-api/service/api/v1/projects/11873/defects/17 HTTP/1.1
Host: yourserver.com
Connection: keep-alive
Accept: application/json
Authorization: Basic am9obkBleGFtcGxlLmNvbTpwQHNzd29yZA==

Der Server gibt einen HTTP-Statuscode und Informationen zum Fehler zurück. Im Beispiel unten gibt der HTTP-Statuscode 200 an, dass die Anfrage erfolgreich war, und zeigt ein JSON-Objekt mit Informationen zum Fehler an:

 
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 1758

{
"id": 17,
"title": "Floating toolbar improvements",
"status": "Resolved",
"__permissions": {
"acl": 7
},
"act_finish": "2015-06-31T00:00:00.0000000",
"act_hrs": 0,
"act_start": "2015-06-17T00:00:00.000000",
"actual_results": "The design of the floating toolbar is inconsistent.",
"assigned_to_name": "Smith, John",
"assignee_user_id": 27942,
"closed_by": 27942,
"custom_fields": [
{
"Id": "Custom1",
"Name": "Components",
"Value": "UI"
},
{
"Id": "Custom2",
"Name": "Fixed in build",
"Value": "1.0.13"
}
],
"date_closed": "0001-01-01T00:00:00.0000000",
"date_created": "2015-05-26T10:54:21.0930000",
"date_opened": "2015-05-27T11:42:29.1700000",
"date_resolved": "2015-06-24T09:55:25.4500000",
"date_updated": "2015-06-24T09:55:25.4500000",
"description": "The design of the floating toolbar needs improvement",
"est_finish": "0001-01-01T00:00:00.0000000",
"est_hrs": 0,
"est_hrs_remaining": 0,
"est_start": "0001-01-01T00:00:00.0000000",
"expected_results": "This should work",
"folder_id": 52359,
"folder_name": "UI Defects",
"functional_area_code": "",
"how_found_code": "Code Review",
"import_id": 0,
"issue_code": "Code Defect",
"nbr_events": 0,
"nbr_files": 1,
"nbr_notes": 1,
"nbr_tasks": 0,
"opened_by": 27942,
"opened_by_company": "EDGB",
"opened_by_email": "smith.john@edgb.com",
"opened_by_name": "Smith, John",
"original_id": 0,
"owner_name": "Smith, John",
"owner_user_id": 27942,
"pct_complete": 0,
"priority_code": "1-Fix ASAP",
"project_id": 11873,
"resolution": "Toolbar is redesigned",
"resolution_code": "Fixed",
"resolved_by": 27942,
"resolved_by_name": "Smith, John",
"severity_code": "1-Crash",
"software_version_code": "1.0",
"steps_to_repro": "step 1\r\nstep 2\r\nstep 3\r\nstep 3.1\r\nstep 3.2\r\n",
"update_user_id": 27942,
"user_name": "Smith, John"
}

Sie sehen, dass diese Antwort nicht so lang ist wie die Antwort der SOAP-API. Da REST-APIs meist Antworten mit weniger Daten und im JSON-Format senden, erfordern sie weniger Bandbreite als SOAP-APIs.

Im Weiteren stellen wir spezielle Anwendungsfälle für SOAP und REST vor.

Wann SOAP verwendet werden sollte

Schauen wir uns zuerst Anwendungsfälle für SOAP-APIs an:

Entwicklung privater APIs, vor allem in Großunternehmen

Mit SOAP können Daten in einer dezentralisierten, verteilten Umgebung übertragen werden. Außerdem bietet SOAP viele Websicherheitsmechanismen. Diese Eigenschaften machen SOAP zu einer idealen Lösung für Unternehmen.

Arbeit mit zustandsbehafteten Operationen

Im Gegensatz zu REST-APIs sind SOAP-APIs zustandsbehaftet. Das heißt: Der Server speichert Informationen über den Client und nutzt diese Informationen über eine Reihe von Anfragen oder aufeinanderfolgenden Vorgängen. Dies ist besonders wichtig für die Durchführung sich wiederholender oder verketteter Aufgaben wie Banküberweisungen, auch wenn dafür mehr Ressourcen und Bandbreite erforderlich sind.

Verwendung eines anderen zugrunde liegenden Transportprotokolls als HTTP

SOAP ist nicht an ein zugrunde liegendes Transportprotokoll gebunden, sodass die Verwendung von HTTP nicht erforderlich ist. Stattdessen kommen je nach Anwendung auch SMTP (Simple Mail Transfer Protocol), JMS (Java Messaging Service) oder andere Transportprotokolle infrage.

Wann REST verwendet werden sollte

Und nun zu den Anwendungsfällen für REST-APIs:

Entwicklung öffentlicher APIs

REST-APIs werden oft als benutzerfreundlicher und leichter umsetzbar angesehen. Daher sind sie ideal für das Erstellen öffentlicher Webservices geeignet. REST fehlen einige der integrierten Sicherheitsfunktionen von SOAP, die jedoch für die Arbeit mit öffentlichen Daten und Services nicht erforderlich sind.

Arbeiten mit begrenzten Serverressourcen und eingeschränkter Bandbreite

Alle Aufrufe einer REST-API müssen zustandslos sein. Das heißt, dass jede Interaktion unabhängig ist. Somit muss jede Anforderung und Antwort alle erforderlichen Informationen zum Abschluss der Interaktion enthalten. Da der Server jede Anforderung als brandneu interpretiert, speichert er keine Informationen zu früheren Anforderungen.

Dadurch verringert sich der erforderliche Serverspeicher erheblich. Die Leistung wird verbessert, denn der Server muss beim Erfüllen einer Anfrage keine zusätzlichen Aktionen ausführen oder frühere Daten abrufen.

Da REST zustandslos ist können Daten zwischengespeichert werden. Auch dies spart Serverressourcen und Bandbreite. Und schließlich können REST-APIs verschiedene Datenformate verwenden, darunter JSON, was einfacher ist als XML. Daher sind REST-APIs schneller und effizienter als die meisten SOAP-APIs.

Erstellung von mobilen Apps

Da REST leicht, effizient, zustandslos und zwischenspeicherbar ist, eignet es sich hervorragend für mobile Apps.

Fazit: Die Entscheidung zwischen REST und SOAP

Beim Erstellen von APIs gibt es keine goldene Regel. Ob Sie sich beim Erstellen von APIs für SOAP oder REST entscheiden, hängt von verschiedenen Faktoren ab, darunter der Programmiersprache und Ihrer Zeit.

Titelbild: / iStock / Getty Images Plus