Jedes Mal, wenn Sie sich mit Ihrem Facebook-Konto bei einer Website anmelden oder in der Mitfahr-App eine Stecknadel über eine Google-Karte ziehen, kommuniziert die von Ihnen verwendete Anwendung über eine Web-API mit Google oder Facebook. Eine API oder Anwendungsprogrammierschnittstelle ist eine Art Vereinbarung zwischen Webdiensten darüber, wie sie Daten austauschen, z. B. eine Karte oder Ihre Kontoanmeldeinformationen abrufen. Die Daten selbst sind in Nachrichten strukturiert, die Systeme untereinander senden. Sobald Sie beispielsweise die Uber-App öffnen, sendet Ihr Telefon eine Nachrichtenanforderung an Google Maps und Google gibt die Karte selbst zurück.
Und wenn Sie sich schon einmal mit Webdiensten beschäftigt haben, wissen Sie wahrscheinlich, dass es mehr als eine Möglichkeit gibt, eine Web-API zu erstellen. Das moderne Web wird von APIs beherrscht, die das REST-Muster verwenden. Es ist ein leichtgewichtiger und effizienter Datenaustausch. Aber manchmal stößt man auf einen anderen Ansatz – das SOAP-Protokoll. Es brüstet sich nicht mit seiner Einfachheit und ist nicht so schnell wie REST. Aber Sie wären überrascht, wie häufig es im Unternehmensdatenaustausch vorkommt, denn SOAP hat seine Vorteile.
In diesem Artikel erfahren Sie, wie SOAP funktioniert, warum es bei Unternehmensbenutzern so weit verbreitet ist und worin es sich von REST unterscheidet.
Zeit für ein paar Worte zur Vorsicht: In diesem Artikel werden technische Begriffe wie Server, Client, Protokolle usw. verwendet. Auch wenn die meisten davon erklärt werden, sollten Sie, wenn Sie noch unsicher sind, unseren anfängerfreundlichen Artikel über Webarchitektur lesen . Er ist ein praktischer Ausgangspunkt für alle, die gerade erst mit der Technik anfangen.
Was ist SOAP?
SOAP oder Simple Objects Access Protocol ist ein Webkommunikationsprotokoll, das 1998 für Microsoft entwickelt wurde. Heute wird es hauptsächlich verwendet, um Webdienste bereitzustellen und Daten über HTTP/HTTPS zu übertragen. Aber es ist nicht darauf beschränkt. SOAP unterstützt im Gegensatz zum REST-Muster nur das XML-Datenformat und folgt streng voreingestellten Standards wie Nachrichtenstruktur, einer Reihe von Kodierungsregeln und einer Konvention für die Bereitstellung von Prozeduranforderungen und -antworten.
Die integrierte Funktionalität zum Erstellen webbasierter Dienste ermöglicht es SOAP, Kommunikationen abzuwickeln und Antworten sprach- und plattformunabhängig zu erstellen.
Während der Großteil des Webdatenaustauschs über REST-Austausch erfolgt, wird SOAP nicht so schnell verschwinden, da es stark standardisiert ist, in bestimmten Fällen Automatisierung ermöglicht und sicherer ist. Werfen wir einen Blick auf die wichtigsten SOAP-Funktionen.
SOAP funktioniert nur mit XML
Über das Web übertragene Daten sind normalerweise irgendwie strukturiert. Die beiden beliebtesten Datenformate sind XML und JSON.
XML (oder Extensible Markup Language) ist ein Textformat, das eine Reihe von Regeln festlegt, um Nachrichten als sowohl menschen- als auch maschinenlesbare Datensätze zu strukturieren. XML ist jedoch sehr ausführlich, da es darauf abzielt, ein Webdokument mit all seiner Formalität zu erstellen. JSON hingegen hat eine lockere Struktur, die sich auf die Daten selbst konzentriert. Sehen Sie sich das Bild unten an, um einen Eindruck davon zu bekommen.
Wie bereits erwähnt, erfordert SOAP beim Senden von Anfragen und Antwortnachrichten innerhalb von Webanwendungen einen XML-Austausch zwischen Systemen. Und wenn die Anfrage empfangen wird, senden SOAP-APIs Nachrichten nur XML-codiert zurück.
Neben dem Datenformat verfügt SOAP über eine weitere Standardisierungsebene – seine Nachrichtenstruktur.
SOAP-Nachrichtenstruktur
XML ist nicht der einzige Grund, warum SOAP im Vergleich zu REST als ausführlich und schwerfällig gilt. Es liegt auch an der Art und Weise, wie SOAP-Nachrichten zusammengestellt werden. Standardmäßige SOAP-API-Anfragen und -Antworten erscheinen als umhüllte Nachricht, die aus vier Elementen mit jeweils spezifischen Funktionen besteht.
Der Umschlag ist das Kern- und wesentliche Element jeder Nachricht. Er beginnt und beendet Nachrichten mit seinen Tags und umhüllt sie, daher der Name.
Der Header (optional) bestimmt die Einzelheiten und zusätzlichen Anforderungen für die Nachricht, z. B. die Authentifizierung.
Der Text enthält die Anfrage oder Antwort.
Der Fehler (optional) zeigt alle Daten zu etwaigen Fehlern an, die während der API-Anfrage und -Antwort auftreten können.
SOAP-Erweiterbarkeit mit WS-Standardprotokollen
Allerdings stellt SOAP selbst grundlegende Strukturelemente der Nachricht bereit. Es schreibt jedoch nicht vor, was in Header und Textkörper gehört. Grundsätzlich können Sie diese Inhalte nach Bedarf anpassen.
Da Webanwendungen jedoch im Allgemeinen häufige Probleme lösen, wurde das Hauptprotokoll nach der Veröffentlichung von SOAP um zahlreiche Standardprotokolle erweitert , die angeben, wie Sie vorgehen. Alle diese Protokolle sind normalerweise mit WS-(Protokollname) gekennzeichnet, z. B. WS-Security, WS-ReliableMessaging. Sie wurden von verschiedenen Organisationen bereitgestellt, darunter Microsoft, IBM, OASIS und andere.
Standardprotokolle decken mehrere Bereiche und Facetten der SOAP-Verwendung ab:
- Sicherheit
- Nachrichten
- Transaktionen
- Metadaten usw.
Das Tolle an diesen Protokollen ist, dass Sie auswählen können, welches Sie verwenden. Dies wird normalerweise als SOAP-Erweiterbarkeit bezeichnet. Wenn Sie beispielsweise Sicherheit für Ihre Finanztransaktionen benötigen, können Sie ACID-kompatible WS-Atomic Transactions verwenden.
ACID-Konformität
ACID steht für Atomicity, Consistency, Isolation und Durability ( Atomizität, Konsistenz, Isolation und Durability ). Dies ist eine Transaktionsqualität auf Unternehmensebene und einer der Gründe, warum SOAP noch immer zum Austausch vertraulicher Informationen in Unternehmensarchitekturen verwendet wird .
ACID-Konformität bedeutet, dass Transaktionen die folgenden Anforderungen erfüllen:
Atomizität. Mehrere verbundene Transaktionen funktionieren entweder als eine Einheit oder überhaupt nicht. Dies wird auch als Alles-oder-Nichts- Ansatz bezeichnet. Dieser Satz von Transaktionen wird mit einem Atom verglichen, das aus mehreren eng verbundenen Elementen besteht.
Konsistenz. Wenn ein Teil einer Transaktion fehlschlägt, wird das System in seinen ursprünglichen Zustand zurückgesetzt.
Isolation. Transaktionen sind voneinander unabhängig.
Durabilität. Selbst wenn das System ausfällt, bleiben abgeschlossene Transaktionen bestehen.
Wenn Sie WS-Atomic Transaction verwenden, ein anderes Standardprotokoll, erreichen Sie ACID-Konformität.
Web Service Description Language (WSDL)-Dokument
Eines der Hauptmerkmale von SOAP-APIs ist, dass sie fast immer ein WSDL-Dokument verwenden.
Einfach ausgedrückt ist ein WSDL-Dokument eine XML-Beschreibung eines Webdienstes. Es dient als Leitfaden für die Kommunikation mit einem Webdienst, definiert die Endpunkte und beschreibt alle Prozesse, die von den bereitgestellten Anwendungen ausgeführt werden könnten. Dazu können Datentypen gehören, die in den SOAP-Nachrichten verwendet werden, und alle über den Webdienst verfügbaren Aktionen. Somit dient eine WSDL-Datei als unterzeichneter Vertrag zwischen einem Client und einem Server.
Das Coole an WSDL ist, dass Sie damit clientseitigen Code in verschiedenen Sprachen generieren und sofort mit der Nachrichtenübermittlung an den Server beginnen können. Obwohl nicht alle SOAP-APIs WSDL-Dokumente nutzen, ist ihre Verwendung so beliebt, weil sie verschiedenen Programmiersprachen und IDEs hilft, die Kommunikation schnell einzurichten.
Weitere Informationen zur technischen Dokumentation finden Sie in unserem speziellen Artikel.
Übertragungsprotokolle: HTTP, TCP, SMTP, FTP und mehr
Einfach ausgedrückt ist ein Übertragungsprotokoll eine Reihe von Regeln und Befehlen, die zum Übertragen von Daten über das Internet verwendet werden. Es gibt Protokolle auf niedriger Ebene wie IPv4, das einfach Datenpakete von einem Punkt zum anderen überträgt. Es gibt höhere Übertragungsschichten wie TCP, die sicherstellen, dass Daten tatsächlich übermittelt werden. Und schließlich gibt es Protokolle auf Anwendungsebene, die von Webbrowsern zur Kommunikation mit Webservern verwendet werden, die jedoch nicht die Verbindung selbst verwalten.
SOAP unterstützt eine Vielzahl von Übertragungsprotokollen, sowohl auf hoher als auch auf niedriger Ebene. Beispielsweise ermöglicht SOAP die Nachrichtenübermittlung über TCP (Transaction Control Protocol), eine Methode zum Datenaustausch auf niedriger Ebene, die zwischen Ports über ein IP-Netzwerk funktioniert. Sie können sich für die Option SMTP (Simple Mail Transfer Protocol) entscheiden, ein Kommunikationsprotokoll für die Übertragung elektronischer E-Mails, FTP (File Transfer Protocol) und jede andere Übertragungsmethode, die den Austausch von Textdaten unterstützt.
Ist es sinnvoll, Daten mit anderen Protokollen als HTTP/HTTPS zu senden? In den meisten Fällen nicht. SOAP wurde in erster Linie für die Verwendung mit HTTP entwickelt. Es kann jedoch Szenarien geben, wie beispielsweise Sicherheitseinschränkungen, Serveranforderungen, Lösungsarchitekturen oder einfach nur Geschwindigkeit, die von dieser SOAP-Vielseitigkeit profitieren.
SOAP WS-Sicherheit
SOAP wird für seine Fähigkeit geschätzt, die WS-Security -Funktion zu integrieren . Dieser Satz von Protokollen bestimmt, wie Sicherheit in den Transaktionen implementiert wird, und schlägt Datenschutz und -integrität vor. Außerdem ermöglicht es Verschlüsselung und kryptografische Signatur.
WS-Security ermöglicht die Verschlüsselung Ihrer Nachrichten nicht nur per HTTPS (das bereits eine Verschlüsselung enthält), sondern auch auf Nachrichtenebene mit Authentifizierungsdaten im Header-Element. Dies muss sichergestellt werden, dass Ihre Daten, wenn sie den Server über HTTPS erreichen, nur vom richtigen Prozess innerhalb dieses Servers gelesen werden können und nicht vom richtigen Server selbst. Da auf der Serverseite eine Datenvorverarbeitung stattfinden kann, bevor die Nachricht den vorgesehenen Prozess erreicht.
Vittorio Bertocci, leitender Programmmanager bei Microsoft, erläuterte die Funktionsweise von WS-Security anhand der Metapher eines nackten Motorradfahrers.
Stellen Sie sich Ihre Nachricht als nackten Motorradfahrer vor. Um das Ziel zu erreichen, kann er durch einen transparenten Tunnel fahren und hoffen, dass ihn niemand sieht (HTTP). Oder er kann durch einen undurchsichtigen Tunnel fahren. In diesem Fall sieht ihn zwar niemand, wenn er sich im Tunnel befindet, aber um das endgültige Ziel zu erreichen, muss er dennoch einige Straßen überqueren (HTTPS ist offensichtlich ein undurchsichtiger Tunnel). Und schließlich kann er einfach Kleidung und einen Helm tragen, um sich vollkommen sicher zu fühlen (WS-Security).
Diese Sicherheit auf Nachrichtenebene ist der Grund, warum sich Finanzorganisationen und andere Unternehmensbenutzer für SOAP entscheiden.
SOAP-Messaging mit und ohne Status
Der Beginn des 21. Jahrhunderts ist für den Internetboom bekannt. Tausende internetbasierte Unternehmen entstanden und Millionen von Benutzern griffen täglich auf das Internet zu. Stellen Sie sich nun vor, dass ein einzelner Server gleichzeitig Tausende von Anfragen von Benutzern (Clients) empfängt. Und wenn diese Ressource etwas Komplexeres tut, als Textwände anzuzeigen, kann es langsam werden. Wenn Benutzer beispielsweise den Zeitplan für bevorstehende Flüge prüfen und jedes Flugdetail aufschlüsseln müssen, muss der Server wissen, was mit dem Client geschieht, richtig?
Es scheint, dass Sie diese Situation auf zwei Arten handhaben können: mit zustandsbehafteten und zustandslosen Vorgängen. Und SOAP unterstützt beide.
Zustandsbehaftet bedeutet, dass der Server die Informationen, die er von einem Client erhält, über mehrere Anfragen hinweg behält. Beispielsweise merkt er sich zuerst die Flugdaten, nach denen Sie suchen, und stellt dann nach der zweiten Anfrage Informationen zu den Preisen bereit. Auf diese Weise können Sie Nachrichten aneinanderreihen und den Server über die vorherigen Anfragen informieren. Zustandsbehaftete Nachrichten können bei Vorgängen mit mehreren Parteien und komplexen Transaktionen, z. B. Bankgeschäften oder Flugbuchungen, von entscheidender Bedeutung sein. Aber dennoch ist es für einen Server sehr belastend.
Zustandslose Kommunikation bedeutet, dass jede Nachricht genügend Informationen über den Zustand des Clients enthält, sodass sich ein Server nicht damit befassen muss. Sobald der Server die angeforderten Daten zurückgibt, vergisst er den Client. Jede Anforderung ist von der vorherigen isoliert. Zustandslose Vorgänge tragen dazu bei, die Serverlast zu reduzieren und die Kommunikationsgeschwindigkeit zu erhöhen. Zustandsbehaftete Vorgänge
sind einer der Gründe, warum SOAP für Banktransaktionen und anderen Datenaustausch verwendet wird, der eine Nachrichtenverkettung erfordert. Weitere Anwendungsfälle von SOAP finden Sie weiter unten.
Wiederholungslogik
Beim Erstellen einer SOAP-API können Entwickler eine Erfolgs-/Wiederholen-Logik integrieren. Einfach ausgedrückt: Wenn etwas schief geht, erhält eine anfordernde Partei die XML-Nachricht mit einem Fehlercode und seiner Erklärung. So versteht ein clientseitiger Entwickler den Grund für den Fehler und kann die Anforderung optimieren, um eine erfolgreiche Antwort zu erhalten. Diese Funktion verleiht dem Entwicklungsprozess etwas Vertrauen, da Sie nicht manuell nach dem Problem suchen müssen. SOAP verfügt über eine Standardspezifikation zum Festlegen des Antwortformats.
SOAP ist vielseitig, leistungsstark und sehr standardisiert. Aber manchmal muss die Schnittstelle nicht so umfangreich sein. Und SOAP hat mehrere Nachteile, die für die Mehrheit der Ingenieure und ihrer Organisationen leicht den Ausschlag zugunsten von REST geben.
Einige zu berücksichtigende Nachteile von SOAP
Ressourcenintensiv. Aufgrund der größeren Größe einer XML-Datei und der Nutzlast, die durch die massive Struktur einer Nachricht entsteht, benötigt eine SOAP-API eine größere Bandbreite. Manchmal lohnt sich dieser Kompromiss nicht. Einfach ausgedrückt ist die Verarbeitung dieser Tag-Strings, von denen XML-Nachrichten nur so wimmeln, langsam.
Steile Lernkurve. Da SOAP-API -Server protokollbasiert sind, erfordert der Aufbau von SOAP-API-Servern Kenntnisse und ein Verständnis aller Protokolle, die Sie damit verwenden können. Entwickler, die mit dem Aufbau dieser Art von APIs zu tun haben, sollten sich eingehend mit allen Prozessen innerhalb des Protokolls mit seinen stark eingeschränkten Regeln befassen.
Mangelnde Flexibilität. Wir haben erwähnt, dass eine SOAP-API als strikter Vertrag zwischen einem Client und einem Server dient. In dieser Hinsicht erfordert dieses starre SOAP-Schema zusätzlichen Aufwand, um die Nachrichteneigenschaften auf beiden Seiten der Kommunikation, dem Server und dem Client, hinzuzufügen oder zu entfernen. Es macht das Aktualisieren von Anfragen und Antworten zu einem langwierigen Prozess und verlangsamt die Einführung.
Erste Schritte mit SOAP: Wichtige Quellen
Wenn Sie gerade erst mit der SOAP-Entwicklung beginnen, sollten Sie sich die folgenden Links ansehen:
SOAP-Dokumentation – die wichtigste Informationsquelle für alle, die mit SOAP arbeiten
SOAP-Versionen – da es mehrere Iterationen des Protokolls gab, sehen Sie sich diese SOAP-Versionen an
WSDL – wie man Web Services Description Language verwendet und WSDL-Dokumente erstellt
WS-Adressierung – wie man Routing-Informationen zu SOAP-Headern hinzufügt
WS-ReliableMessaging – die Erweiterung, die sicherstellt, dass die Nachrichten an ihren Zielen ankommen. Sie hilft auch beim Erstellen von Nachrichtenketten
WS-Koordination – Koordinieren von Aktionen verteilter Anwendungen
WS-Sicherheit – wie man Schutz auf Nachrichtenebene aktiviert
WS-Atomic Transaction – wie man Nachrichten ACID-kompatibel macht
Vergleich zwischen SOAP und REST
Bei der Beschreibung von SOAP müssen wir seine wichtigste Alternative erwähnen – REST.
REST oder Representational State Transfer ist ein Architekturstil und kein Protokoll. Das bedeutet, dass REST viel mehr Flexibilität bietet, was die Strukturierung Ihrer Nachricht, das verwendete Format und die Skalierung von Client und Server betrifft. SOAP hingegen erfordert eine enge Kopplung zwischen Client und Server. Wenn eine der beiden Seiten etwas ändert, geht etwas schief, daher seine Protokollnatur.
REST wurde im Jahr 2000 eingeführt – es ist nicht viel jünger als SOAP – mit der Idee, dass sich Server weniger darum kümmern sollten, was auf dem Client passiert.
Und hier beginnt einer der Hauptunterschiede zwischen REST und SOAP.
Zustandsbehaftete und zustandslose Vorgänge. REST ist so konzipiert, dass es zustandslos ist; SOAP unterstützt beide Ansätze.
Nachrichtenstruktur. Während die SOAP-Nachricht ein „Umschlag“ ist, befindet sich die REST-Nachricht auf einer „Postkarte“: Sie hat keine zusätzlichen Umschläge oder Kopfzeilen oder irgendetwas anderes, das ihre leichte Natur verändern würde.
Logikdarstellung. Im Gegensatz zu SOAP, das seine Logik im WSDL-Dokument behält, hat REST seine Alternative – ein WADL-Dokument (oder Web Application Description Language-Dokument). Es ist nicht so verbreitet wie WSDL, aber manchmal ist es nützlich, wenn Sie in einer Unternehmensumgebung arbeiten und Leute von der Serviceseite aus nicht einfach kontaktieren können, sodass Sie einige formale Konventionen zur Hand haben müssen.
Datenformate. Wie bereits erwähnt, ist SOAP streng XML. REST kann mit JSON, XML, HTML und anderen Formaten arbeiten, die Sie mögen. Aber JSON (oder JavaScript Object Notation) bleibt das beliebteste.
Übertragungsprotokolle. SOAP ist in Bezug auf Übertragungsprotokolle flexibel, um mehreren Szenarien gerecht zu werden. REST konzentriert sich ausschließlich auf den HTTP/HTTPS-Austausch. Es kann einige Ausnahmen geben, wenn Sie HTTP-Austauschmethoden (GET, POST PUT, DELETE usw.) beispielsweise FTP-Methoden zuordnen. REST wurde jedoch im Hinblick auf HTTP entwickelt.
Caching. Caching bedeutet, einige Informationen auf der Clientseite zu speichern, um zusätzliche Belastung des Servers zu vermeiden. Sie können zum Beispiel nicht dynamische Inhalte wie Bilder zwischenspeichern, um sie clientseitig schneller zu laden und zu vermeiden, dass Sie bei jedem Besuch einer Ressource eine entsprechende Aufforderung an den Server senden müssen. REST ermöglicht das Zwischenspeichern von Daten auf HTTP-Ebene. Wenn Sie SOAP-Caching implementieren möchten, müssen Sie ein zusätzliches Cache-Modul konfigurieren . Im Allgemeinen ist REST cachefreundlicher.
Nachrichtengröße . Das Fehlen der Overhead-Text- und Codeblöcke in der einfachen JSON-Datei im Vergleich zum unhandlichen XML in SOAP führt zu einer erheblichen Größenreduzierung. Das bedeutet, dass die JSON-Datei einer einfachen RESTful-API einfacher und schneller zu verarbeiten und zu übertragen ist.
Lernkurve. Die RESTful-Architektur ist unkompliziert und einfach zu erreichen. SOAP erfordert ein viel tieferes Verständnis von Standards und zusätzlichen WS-Protokollen. Darüber hinaus ist die Engineering-Community, die sich mit REST beschäftigt, größer. Sie können also erwarten, viel schneller Antworten auf Probleme zu finden generative ai.
Fehlerbehandlung. Im Gegensatz zu einer SOAP-API, deren Spezifikation die Rückgabe der Retry-XML-Nachricht mit Fehlercode und Erklärung zulässt, lässt eine REST-API weniger Raum für Transparenz. REST bietet hauptsächlich zwei Optionen: Die Antwort kann den Fehlercode ohne Erklärung enthalten. Dies ist eine Standardfunktion. Andererseits ermöglicht die Technologie die manuelle Vorgabe eines Fehlerobjekts zusammen mit seinem Code.
Sicherheit.Eine REST-API verwendet Secure Sockets Layer (oder SSL) zusammen mit HTTPS über HTTP und verfügt über einen einfachen Transportmechanismus als Verschlüsselungsmethode. Die HTTPS-Abdeckung dient als Schutzschild für die Datensicherheit. Und das SSL-Sicherheitsprotokoll wird über eine HTTPS-Verbindung angewendet, um REST-API-Aufrufe zu verifizieren. Mit SOAP können Sie zusätzlich zur Sicherheit auf Nachrichtenebene auch SSL, einschließlich TCP-Messaging, verwenden.
SOAP-Anwendungsfälle
Angesichts dieser Unterschiede wird deutlich, warum Web-Messaging meist mit REST erfolgt. Um die Dinge abzuschließen, definieren wir die Fälle, in denen SOAP immer noch die Haupttechnologie ist.
Hochstandardisierte Vorgänge: Abrechnung, Navigation, Einrichtungen. Alle Anwendungsfälle, in denen Sie jede Art von Fehlinterpretation vermeiden müssen, eignen sich gut für die SOAP-Kommunikation. Normalerweise haben diese Systeme strenge Verträge mit klar definierter Logik, die mit einem WSDL-Dokument beschrieben werden kann.
Banktransaktionen und Zahlungssysteme. Wenn Ihre Transaktionen immer zuverlässig und für Dritte unerreichbar sein müssen, bietet SOAP mehrere Vorteile, die Sie berücksichtigen sollten. Erstens ist es das Sicherheitsniveau mit ACID-Konformität und WS-Security-Protokollen. Darüber hinaus erfordert dieser Satz von Anwendungsfällen normalerweise Stateful Messaging, d. h. die Verwendung von verketteten Transaktionen, die nicht voneinander isoliert sind. Da bei Zahlungssystemen mehrere Parteien an einer einzigen Operation beteiligt sein können, ermöglicht SOAP eine bessere Koordination ihres Verhaltens.
Flugbuchungssysteme. Da an der Flugbuchung normalerweise mehrere Parteien beteiligt sind, verlassen sich einige Anbieter aus dieser Branche immer noch auf SOAP, um Stateful und Chained Messaging abzuwickeln.
Nicht-HTTP-Messaging und Legacy-Umgebungen. Wenn die Serveranforderungen und vorhandenen Systeme andere Kommunikationsprotokolle als HTTP nutzen, ist SOAP die erste Option, die in Betracht gezogen werden sollte.