SOAP vs. REST: Lösen der Testherausforderungen von jedem

Möglicherweise sind Sie bereits mit SOAP und REST vertraut. Schließlich sind SOAP und REST gut etabliert und ihre Definitionen und Spezifikationen reichen Jahrzehnte zurück. Möchten Sie Ihr Wissen erweitern oder eine neue Perspektive gewinnen? Oder haben Sie vielleicht schon von beidem gehört und möchten es besser verstehen?

Bitte erlauben Sie mir, die SOAP- und REST-Unterschiede zu beschreiben, zu vergleichen und auf andere Weise Licht auf diese beiden wichtigen Ansätze für das Design von Webdiensten und Web-APIs zu werfen. Ich werde auch einige der mit diesen Ansätzen verbundenen Testherausforderungen und deren Lösung hervorheben. Lassen Sie uns zunächst definieren, was diese sind und welchen Bezug sie zum World Wide Web haben.

Unterschied zwischen SOAP- und REST-Webdiensten

Das World Wide Web Consortium (W3C) empfiehlt Standards und Protokolle für die globale Sammlung miteinander verbundener Ressourcen, die wir als World Wide Web kennen. Auf eine "Web" -Ressource wird unter einer "Web" -Adresse zugegriffen und über ein "Web" -Protokoll bereitgestellt.

Wenn Sie diesen Blogbeitrag lesen, wissen Sie möglicherweise, dass Sie unter der in der Adressleiste Ihres Browsers angezeigten URL ein HTML-Dokument lesen, das über das HTTP(S)-Protokoll angefordert und übermittelt wurde. Das W3C hat definiert, wie dieselben Technologien, die Ihnen das Lesen dieses Blogbeitrags ermöglichen, die Kommunikation zwischen Softwaresystemen erleichtern können. Insbesondere definierte das W3C „Webdienste“, was im Laufe der Jahre zur Schaffung vieler anderer Standards und Technologien führte. Werfen wir einen allgemeinen Blick darauf, was sie sind.

SOAP verstehen

SOAP ist eine Abkürzung für Simple Object Access Protocol. Es handelt sich um ein objektorientiertes Protokoll, bei dem Objekte zwischen Client und Server ausgetauscht und in und aus XML serialisiert werden. Die SOAP-Spezifikation baut auf anderen vom W3C definierten Webtechnologien auf, einschließlich XML und HTTP. Viele Spezifikationen basieren auf der SOAP-Spezifikation oder erweitern diese, darunter auch einige, die nicht so einfach sind. Ein SOAP-Dienst tauscht SOAP-Nachrichten mit einem SOAP-Client aus.

Bevor ich anfange, die verschiedenen Qualitäten von SOAP und deren Vergleich mit REST näher zu erläutern, beginnen wir damit, zu erklären, wie SOAP überhaupt entstanden ist. Die Geschichte von SOAP beginnt eigentlich mit der Geschichte von XML und dem Web selbst. XML wurde nach dem Erfolg von HTML, dem Datenformat für die Anzeige von Dokumenten in Webbrowsern, für das Web entwickelt.

XML sollte wie HTML sowohl für Menschen lesbar als auch maschinenlesbar sein und über das Web bereitgestellt werden. XML wurde entwickelt, um beliebig strukturierte Daten zu verpacken und zu versenden, wofür HTML nicht geeignet war. Wie sich herausstellte, löste XML nur einige Probleme, die zur Einführung von SOAP führten.

Die Kommunikation zwischen Anwendungen über das Web stellt verschiedene Interoperabilitätsherausforderungen dar, insbesondere wenn Anwendungen in verschiedenen Sprachen mit unterschiedlichen Datentypen entwickelt werden. Beispielsweise kann eine Webanwendung mit PHP erstellt werden, eine andere mit .NET und eine andere mit Java. Um den Herausforderungen der Interoperabilität zu begegnen, besteht ein Ansatz darin, XML als Datenaustauschformat zu verwenden.

XML bietet eine standardisierte Möglichkeit zur Beschreibung beliebiger, strukturierter Daten. Andere Spezifikationen wie das XML-Schema definieren ein gemeinsames Typsystem, unabhängig von den verwendeten Programmiersprachen. Die Verwendung von XML stellt jedoch eine weitere Herausforderung dar: Es gibt keine Standardmethode, um zu beschreiben, wie die Daten innerhalb von XML organisiert oder verarbeitet werden sollen. SOAP wurde als programmiersprachenunabhängiges Framework für Remoteprozeduraufrufe basierend auf XML und XML-Schema entwickelt.

SOAP definiert eine Reihe von Regeln für die Nachrichtenstruktur und -kommunikation. Eine SOAP-Nachricht wird auch „Envelope“ genannt. Ein SOAP-Umschlag verfügt über ein „Body“-Element und ein optionales „Header“-Element. Der „Körper“ umhüllt normalerweise ein anderes XML-Dokument oder „hüllt“ es buchstäblich ein. Der Header enthält optionale Details wie Authentifizierung oder Metadaten, während der Body den eigentlichen Inhalt der Nachricht enthält.

Einer der Hauptvorteile von SOAP ist seine Plattform- und Sprachunabhängigkeit, was bedeutet, dass Systeme, die auf verschiedenen Technologien entwickelt wurden, nahtlos über SOAP als Nachrichtenprotokoll kommunizieren können. Darüber hinaus ist SOAP hoch erweiterbar und unterstützt viele Kommunikationsstile, einschließlich Anfrage/Antwort und unidirektionaler Nachrichtenübermittlung. Es wird häufig in Systemen auf Unternehmensebene verwendet, die komplexe Vorgänge und strenge Nachrichtenverträge erfordern.

REST verstehen

REST ist eine Abkürzung für REpresentational State Transfer. Im Gegensatz zu SOAP handelt es sich bei REST nicht um eine spezifische Technologie, sondern um einen Architekturstil, der spezifische Einschränkungen für ein Softwaresystem definiert. Ein REST-kompatibler Webdienst oder eine Web-API wird oft als RESTful API oder REST API bezeichnet.

Wie SOAP nutzen REST-APIs die vorhandene HTTP-Infrastruktur und die Verwendung vorhandener Webstandards, um Interoperabilität zu ermöglichen. REST bietet außerdem einen einfachen und skalierbaren Ansatz für die Kommunikation zwischen Clients und Diensten. RESTful-Dienste basieren auf Ressourcen. Eine Ressource ist eine beliebige abstrakte Entität, die durch einen URI (Uniform Resource Identifier) ​​identifiziert wird.

Eine REST-API lauscht an einem Basis-URI mit untergeordneten Pfaden für den Zugriff auf jede der von der API bereitgestellten Ressourcen. Ein Ressourcenpfad kann einen oder mehrere Parameter enthalten, die zur Identifizierung einer Ressource verwendet werden können, wobei bestimmte Pfadsegmente Identifikatoren enthalten könnten. Ressourcenparameter können auch die Form von Abfrageparametern oder Headern haben. Clients interagieren mit diesen Ressourcen, indem sie HTTP-Anfragen senden und dabei standardmäßige CRUD-Vorgänge verwenden: Erstellen, Lesen, Aktualisieren und Löschen. REST nutzt die Verben des HTTP-Protokolls (GET, POST, PUT, PATCH, DELETE) und Statuscodes, um Operationen an Ressourcen auszuführen und Informationen über die Antwort zu übermitteln.

REST verwendet hauptsächlich JavaScript Object Notation (JSON) zur Datendarstellung. JSON ist ein leichtes und für Menschen lesbares Format, das die Arbeit damit und das Verständnis erleichtert. Es lässt sich auch gut mit modernen Webentwicklungstechnologien und JavaScript-basierten Frameworks kombinieren.

Ein bemerkenswertes Merkmal von REST ist seine Staatenlosigkeit. Jede Anfrage eines Clients an einen RESTful-Dienst enthält alle notwendigen Informationen, um diese Anfrage zu verarbeiten. Der Server behält keinen Sitzungs- oder Clientstatus bei, wodurch er hoch skalierbar ist und einen Lastausgleich über mehrere Server hinweg ermöglicht.

Lassen Sie uns nun einige Details zu den Unterschieden zwischen SOAP und REST untersuchen und verstehen, wie diese Ansätze miteinander verglichen werden

Einkauf & Prozesse

Ein SOAP-Dienst definiert eine Reihe von Vorgängen. Die Operationen können beliebig sein, da es keine Einschränkungen hinsichtlich des Umfangs oder Zwecks der zu definierenden Operationen gibt. Vorgänge verfügen über eine Signatur, die normalerweise den vollständig qualifizierten Namen des Elements im Body-Element des Umschlags darstellt. Der Name des Elements könnte beispielsweise „calculateSomething“ oder „doSomethingFun“ lauten.

Eine REST-API verfügt über eine Sammlung von Vorgängen für jede Ressource. Die verfügbaren Vorgänge sind auf CRUD (Erstellen, Lesen, Aktualisieren und Löschen) beschränkt. Die Vorgänge werden HTTP-Methoden wie GET, POST, PUT, PATCH und DELETE zugeordnet.

Positiver Vergleich

SOAP-Operationen bieten ein höheres Maß an Flexibilität, da sie nicht auf CRUD beschränkt sind und nicht um bestimmte Ressourcentypen wie REST herum strukturiert werden müssen. Operationen können jedoch auch für CRUD verwendet werden, wobei das XML im SOAP-Hauptteil eine XML-Darstellung eines Objekts zusammen mit seiner Kennung enthalten kann.

REST-Operationen bieten einen höheren Grad an Einfachheit. Ein URI wird verwendet, um die Ressource zu identifizieren, entkoppelt von der Darstellung der ausgetauschten Ressource. Darüber hinaus müssen Vorgänge zustandslos sein, was bedeutet, dass sich die Vorgänge konsistent verhalten und nicht auf dem Zustand der Konversation zwischen dem Client und dem Dienstendpunkt basieren.

Kritischer Vergleich

SOAP-Dienste kann eine viel höhere Komplexität aufweisen, indem beliebige Operationen unterstützt werden und möglicherweise der Zustand verfolgt wird. Ein Beispiel könnte ein Buchhandlungsdienst mit einer „addToCart“-Operation sein. Jedes Mal, wenn ein Kunde „addToCart“ aufruft, verfolgt der Dienst den Artikel im Warenkorb des Kunden. Ein anderer Kunde kann „addToCart“ aufrufen, ohne den Warenkorb eines anderen Kunden zu beeinflussen. Der Dienst verfolgt den Status jedes Clients separat.

REST-APIs sind eingeschränkter als SOAP, da die Operationen auf CRUD beschränkt sind. Darüber hinaus haben die Kunden die Last, ihren eigenen Status zu verfolgen. Im Beispiel der Buchhandlung muss der Client die ID seines Einkaufswagens kennen, damit er den richtigen URI für seinen Einkaufswagen erstellen kann, z. B. „cart/{id}“. Der Client könnte an diesem URI ein GET ausführen, um eine strukturierte Darstellung seines Einkaufswagens abzurufen. Der Client könnte auch einen PUT bei demselben URI ausführen, um seinen Einkaufswagen mit einer aktualisierten Darstellung zu aktualisieren.

Daten Präsentation

SOAP-Messaging beinhaltet den Austausch von XML-Dokumenten, sogenannten SOAP-Umschlägen. Ein SOAP-Umschlag enthält ein „Body“-Element und ein optionales „Header“-Element. Der XML-Code im „Body“-Element kann beliebig sein, repräsentiert jedoch typischerweise eine oder mehrere Entitäten oder Objekte. Der Inhaltstyp ist entweder „text/xml“ oder „application/soap+xml“, je nachdem, ob SOAP Version 1.1 oder SOAP Version 1.2 befolgt wird.

XML-Elemente im SOAP können auch zum Umschließen anderer Datentypen, Text- oder Binärdaten, verwendet werden. Das W3C hat Optimierungen namens „XOP“ und „MTOM“ definiert, die beschreiben, wie Binärdaten effizient in XML- und SOAP-Nachrichten als MIME „Multipart/Related“ verpackt werden können, wodurch die Notwendigkeit vermieden wird, die Binärdaten direkt in XML-Tags mit Base64 zu kodieren.

REST-API-Messaging beinhaltet den Austausch von Repräsentationen einer Ressource. Eine „Darstellung“ könnte ein beliebiges Datenformat sein. Dabei kann es sich um ein strukturiertes Datenaustausch-/Austauschformat wie XML oder JSON oder etwas ganz anderes wie PDF oder JPEG handeln. Es gibt keine Inhaltstypbeschränkung. Eine REST-API könnte mehrere Datenformate oder unterschiedliche Datenformate für unterschiedliche Ressourcen unterstützen.

Positiver Vergleich

SEIFE. XML ist standardisiert und gut verstanden und wird durch verschiedene W3C-Empfehlungen definiert. XML verfügt über ein Konzept von Namespaces, mit deren Hilfe Elemente eindeutig unterschieden und Namenskonflikte vermieden werden können. SOAP-Umschläge bieten eine Kapselungsebene, die das Einfügen zusätzlicher Metadaten in das Element „Header“ ermöglicht.

SICH AUSRUHEN. Für REST-APIs gibt es keine Einschränkungen hinsichtlich der Datenformate, die sie verwenden können. Für strukturierte Daten ist die Verwendung von JSON üblich und lässt sich viel schneller verarbeiten und erzeugen als XML. Es gibt jedoch auch andere Formate zur Serialisierung strukturierter Daten, die noch kompakter und effizienter sein können als beispielsweise JSON BSON (binäres JSON) oder Google Protokollpuffer (Protobuf), oder Apache Avro. Jeder Inhaltstyp ist möglich.

Kritischer Vergleich

SEIFE. XML kann im Vergleich zu anderen Datenformaten auch ausführlich oder aufgebläht sein, wobei die Produktions- und Verbrauchskosten relativ hoch sind. Die Nachrichtengröße kann jedoch durch Komprimierung wie das HTTP-Komprimierungsschema „Content-Encoding: gzip“ reduziert werden. Die Serialisierungskosten können durch Verwendung alternativer oder binärer XML-Codierungen wie der von Microsoft reduziert werden .NET Binärformat für XML.

SICH AUSRUHEN. Es gibt kein Standardformat für den Datenaustausch für REST-APIs. Abhängig von der REST-API, mit der Sie kommunizieren, benötigen Sie möglicherweise einen anderen Satz von Bibliotheken, um strukturierte Daten zu nutzen und zu erzeugen. Allerdings ist JSON sehr beliebt und oft verfügbar.

Erweiterbarkeit

SOAP und REST sind erweiterbar, aber auf sehr unterschiedliche Weise. Lassen Sie uns in den Vergleich eintauchen.

Positiver Vergleich

SEIFE. Die Protokollbindung muss nicht HTTP sein, kann aber alles sein. SOAP-Nachrichten können über einige andere TCP-basierte Protokolle wie SMTP oder über UDP-Socket gesendet werden, wie dies in WS-Discovery und UPnP der Fall ist. Das .NET WCF SOAP-Framework von Microsoft verfügt über TCP- und Named-Pipe-Transporte. Ereignisgesteuerte oder Nachrichtenwarteschlangen-Schnittstellen wie JMS (Java Message Service) oder AMQP (Advanced Message Queuing Protocol) werden auch für SOAP verwendet.

SOAP ermöglicht auch verschiedene Nachrichtenaustauschmuster. Es muss nicht unbedingt eine Anfrage-Antwort-Anweisung sein. Es kann asynchron, unidirektional oder „Fire-and-Forget“ sein. SOAP wird in der serviceorientierten Architektur (SOA) verwendet, in der Dienste lose gekoppelt sind, Nachrichten pushen oder auf Nachrichten reagieren, die von einem Enterprise Service Bus (ESB) weitergeleitet werden.

SICH AUSRUHEN. REST-APIs sind dahingehend erweiterbar, dass sie möglicherweise Ressourcen mit unterschiedlichen Nachrichtenformaten darstellen können. Im Gegensatz zu SOAP sind Sie nicht auf XML-basierte Darstellungen beschränkt. Neue Ressourcen können hinzugefügt werden, ohne dass vorhandene Ressourcen beeinträchtigt werden. REST-APIs können versioniert werden, indem eine Versionsnummer oder eine Versionskennung als Teil des URI angegeben wird.

Kritischer Vergleich

SEIFE. Mit der höheren Erweiterbarkeit steigt die Komplexität. Angesichts der verschiedenen Protokolle, Messaging-Muster und WS- * -Spezifikationen, die angewendet werden können, gibt es keine einzige Möglichkeit, SOAP-Messaging zu implementieren.

SICH AUSRUHEN. REST-APIs sind im Allgemeinen auf HTTP beschränkt, wobei Methoden- und Ressourcen-URI im HTTP-Anforderungsheader gesendet werden. RESTful-Ansätze wurden jedoch mit anderen Technologien wie erreicht Constrained Application Protocol (CoAP), eine Implementierung von REST für eingeschränkte Umgebungen für IoT-Anwendungen (Internet der Dinge). RESTful-Prinzipien können auch bei Messaging-Brokern befolgt werden RabbitMQ und MQTT, wobei Ressourcenkennung und CRUD-Vorgang möglicherweise Nachrichtenzielen oder -themen zugeordnet werden könnten.

Flexible Kommunikation

SOAP wurde unter Berücksichtigung der Interoperabilität entwickelt, folgt offenen Standards und ist nicht an eine bestimmte Implementierung, Plattform oder Programmiersprache gebunden. Einige Dinge in der Spezifikation ließen jedoch Interpretationsspielraum. Einige Teile können verwirrend sein oder Fehler, Tippfehler oder schlechte Beispiele enthalten. Die Probleme ergeben sich aus einfachen Dingen wie der Frage, ob:

• Ein bestimmter Wert soll in Anführungszeichen gesetzt werden oder nicht.
• Bestimmte XML-Konstrukte sind in Ordnung oder sollten vermieden werden.
• Bestimmte Arten von Dingen sollten im SOAP-Body erlaubt oder eingeschränkt sein.

Ein weiteres Normungsgremium, das Web Services Interoperability Organization (WS-I)entstand, um Richtlinien für die Interoperabilität von Webdiensten bereitzustellen. Der WS-I bietet verschiedene Interoperabilitätsprofile. Jedes Profil verfügt über eine Liste von Anforderungen und eine Liste von Behauptungen, die definieren, wie die Anforderungen überprüft werden. Kurz gesagt sagen die WS-I-Profile Dinge wie „Das solltest du tun“ und „Das solltest du nicht tun.“

Lustige Tatsache! Parasoft war Mitwirkender am WS-I Basic Profile 1.1 Test Assertions Document (TAD).

REST-APIs sind insofern interoperabel, als sie einfach aufzurufen sind. Es gibt viele Tools und APIs, die HTTP-Anforderungen stellen können. Beliebte Tools sind cURL und Postman. Sogar ein einfaches Formular auf einer Webseite kann verwendet werden, um HTTP-Anfragen zu stellen. Neben HTTP gibt es auch verschiedene offene Standards, die typischerweise für REST-APIs verwendet werden, darunter offene Nachrichtenformate wie JSON. REST-APIs können auch verschiedene offene Standards für Sicherheit und Autorisierung implementieren. Mehr dazu später.

Positiver Vergleich

SOAP wurde unter Berücksichtigung der Interoperabilität entwickelt. Die W3C-SOAP-Spezifikationen werden hauptsächlich von Microsoft verfasst, das über einen eigenen SOAP-Stack verfügt, der als Teil von Microsofts .NET Framework implementiert ist, ursprünglich .NET Web Service Enhancements (WSE) und später .NET Windows Communication Foundation (WCF). Allerdings sind SOAP-Stacks von vielen anderen Anbietern erhältlich, darunter auch Open-Source-Projekte wie das Apache-Projekt. Neben .NET sind SOAP-Stacks auch für verschiedene Plattformen und Programmiersprachen wie Java, Python und TypeScript verfügbar. Mit unterschiedlichen SOAP-Stacks implementierte SOAP-Clients und SOAP-Dienste sind kommunikationsfähig, wenn sie denselben offenen SOAP-Standards folgen.

REST APIs folgen dem KISS-Prinzip („Keep it simple, stupid“) und folgen den allgemeinen Designprinzipien der REST-Softwarearchitektur. REST-APIs sind einfach aufzurufen und erfordern nicht unbedingt einen komplexen Software-Stack, wie Sie ihn normalerweise für die Kommunikation mit SOAP-Endpunkten benötigen.

Kritischer Vergleich

SOAP verfügt über eine Vielzahl von Erweiterungen, die oft als WS-* bezeichnet werden. Es gibt WS-Addressing, WS-Policy, WS-Discovery, WS-MetadataExchange, WS-SecureConversation, WS-SecurityPolicy, WS-Trust und WS-Federation. Es gibt auch WS-Security mit verschiedenen zugehörigen Spezifikationen, darunter solche im Zusammenhang mit XML- und SOAP-Signatur, XML- und SOAP-Verschlüsselung sowie SAML (Security Assertion Markup Language). Die Liste geht weiter und weiter und weiter. Es besteht die Möglichkeit, dass ein SOAP-Dienst mehreren WS-*-Spezifikationen folgt, was die Komplexität dessen erhöht, was ursprünglich als „einfaches“ Protokoll definiert wurde. Ihr Kunde muss die gleichen WS-*-Standards befolgen wie der Dienst, sonst kann er nicht richtig kommunizieren.

REST APIs müssen nicht unbedingt offenen Standards folgen. Obwohl JSON sehr beliebt ist, gibt es kein Standardformat für den Datenaustausch. Jeder Inhaltstyp ist möglich, einschließlich möglicherweise proprietärer Datenformate. Darüber hinaus können bestimmte Sicherheits- oder Autorisierungsframeworks zusätzliche Komplexität mit sich bringen und eine kompatible Implementierung auf der Clientseite erfordern.

Sicherheit

Sicherheit ist sowohl für SOAP als auch für REST ein wichtiger Gesichtspunkt. Die Sicherheit der Transportschicht ist erforderlich, um Nachrichten zu verschlüsseln, wenn sie über das Kabel gesendet werden, um ein Abhören zu verhindern. Die Sicherheit der Nachrichtenschicht ist für eine vollständige End-to-End-Sicherheit erforderlich, sodass die Nachricht vor allen Vermittlern geschützt ist, die möglicherweise Zugriff darauf haben, bevor sie ihr beabsichtigtes Ziel erreicht. Authentifizierungs- oder Autorisierungsmechanismen sind erforderlich, um die Identität zwischen Client und Server herzustellen.

Positiver Vergleich

SOAP verfügt über eine große Sammlung von Sicherheitsspezifikationen, die als WS-Security bekannt sind und von der Normungsorganisation veröffentlicht werden Aftershave. Abgesehen von Sicherheitsmechanismen der Transportschicht wie HTTPS beschreiben die WS-Sicherheitsspezifikationen, wie Sicherheit direkt in die SOAP-Nachrichten selbst eingebettet wird (einschließlich Signaturen, verschlüsselte Daten) und wie Sicherheitstoken zur Identitätsfeststellung wie SAML (Security Assertion Markup Language) verpackt werden.

REST kann vorhandene Mechanismen in HTTP für die Sicherheit nutzen, einschließlich SSL- und HTTP-basierter Authentifizierungsschemata. Es gibt auch offene Standards für die Autorisierung, einschließlich OpenID-Connect (OIDC), das darauf aufbaut OAuthund einige andere offene Spezifikationen wie JSON-Webtoken (JWT).

Kritischer Vergleich

SEIFE. Die OASIS WS-Security-Spezifikationen sind komplex. Dienste, die mehrere WS-Security- und andere WS-*-Spezifikationen implementieren, stellen Baukunden vor Herausforderungen.

• Welche Schlüsselgeschäfte benötige ich?
• Muss ich die Nachricht signieren oder auch verschlüsseln?
• Welchen XML-Kanonisierungsalgorithmus soll ich verwenden?
• Muss ich zuerst ein SAML-Token erhalten und es in einen SOAP-Header einfügen?
• Welche Teile der Nachricht muss ich signieren und verschlüsseln?

SICH AUSRUHEN. Die Sicherheit auf Nachrichtenebene ist nicht Standard, einige sind proprietär. Beispielsweise bietet Amazon AWS serverseitige und clientseitige Mechanismen zum Verschlüsseln von Nachrichten, die an oder von ihren APIs gesendet werden.

Service-Definitionen

Es gibt verschiedene Arten von Dokumentationsformaten für Maschinenverbrauchsmaterialien für SOAP-Services und REST. Service-Definitionsdokumente ermöglichen eine automatisierte Verarbeitung, z. B. die automatisierte Codegenerierung für Clients oder Service-Stubs. Service-Definitionsdokumente können auch in ein benutzerfreundliches Dokumentationsformat wie eine Webseite übersetzt werden.

Positiver Vergleich

SEIFE. SOAP-Dienste werden von WSDL beschrieben, einer weiteren offenen Spezifikation des W3C. Eine WSDL ist ein XML-Dokument. Es definiert die Service-Endpunkte, Operationen und XML-Schemas für Anforderungs-, Antwort- und Fehlermeldungen.

SICH AUSRUHEN. Es gibt verschiedene Service-Definitionsformate für REST-APIs. Diese schließen ein OpenAPI, RAML, API-Blaupause und WADL. Sie alle bieten unterschiedliche Möglichkeiten, Dinge zu beschreiben, die REST-APIs gemeinsam haben, wie Ressourcenpfade, Parameter, Vorgänge sowie Typ und Format oder Schema von Darstellungen.

OpenAPI basiert auf JSON-Schema Spezifikationen und kann entweder als JSON oder YAML dargestellt werden. RAML-Dokumente basieren auf YAML und unterstützen sowohl JSON-Schema als auch XML-Schema (XSD). API Blueprint basiert auf der Markdown-Syntax für die Objektnotation (MSON) mit Unterstützung für das JSON-Schema. WADL ist eine W3C-Übermittlung, die auf XML basiert und die Beschreibung von XML-Darstellungen mithilfe des XML-Schemas unterstützt, etwas analog zu WSDL für SOAP.

Kritischer Vergleich

SEIFE. Die WSDL-Spezifikation enthält einige Probleme mit zusätzlichen Erläuterungen und Interoperabilitätsempfehlungen, die von der Web Services Interoperability Organization (WS-I) bereitgestellt werden. Es gibt auch mehrere Versionen von WSDL. WSDL 1.1 wird am häufigsten implementiert. WSDL 2.0, früher bekannt als WSDL 1.2, wurde nicht von allen SOAP-Stacks übernommen, einschließlich Microsofts .NET WCF. Interessanterweise wurde mit WSDL 2.0 die Unterstützung für die Beschreibung von REST-APIs eingeführt.

SICH AUSRUHEN. Es gibt kein Standard-Service-Definitionsformat für REST-APIs. OpenAPI ist jedoch eine wichtige Überlegung, um der Standard zu sein. OpenAPI wurde ursprünglich von SmartBear als „Swagger“ entwickelt und später als OpenAPI an die Linux Foundation gespendet. Die Spezifikation wird von der überwacht OpenAPI-InitiativeDazu gehören Mitglieder aus einer Vielzahl großer Unternehmen, darunter Google, IBM und Microsoft.

Jedes Servicedefinitionsformat verfügt über eine eigene Sammlung von Tools für die Code- und Dokumentgenerierung. Das bedeutet, dass Sie je nach Serviceimplementierung unterschiedliche Tools verwenden müssen. Es gibt jedoch Konverter, mit denen Sie ein OpenAPI-Dokument in ein RAML oder umgekehrt konvertieren können.

Anwendungsfälle und Beispiele

SOAP und REST können ähnliche Anwendungsfälle abdecken, unterscheiden sich jedoch in der Art und Weise, wie sie Anfragen und Antworten verarbeiten. Nachfolgend finden Sie einige Beispiele.

SOAP-Anwendungsfälle

Hier sind einige Anwendungsfälle von SOAP-basierten Webdiensten.

1. Währungsumrechnungsdienst

Ein Webdienst, der es Kunden ermöglicht, zwischen verschiedenen Währungen umzurechnen. Der Client sendet eine SOAP-Anfrage mit der Quellwährung, der Zielwährung und dem umzurechnenden Betrag. Der Server verarbeitet die Anfrage und sendet eine SOAP-Antwort mit dem umgerechneten Betrag zurück.

2. Flugreservierungssystem

Ein Webservice, der es Kunden ermöglicht, Flüge zu buchen. Der Kunde sendet eine SOAP-Anfrage mit den erforderlichen Flugdetails wie Abflugort, Zielort, Datum und Passagierinformationen. Der Server verarbeitet die Anfrage und sendet eine SOAP-Antwort zurück, die die Reservierung bestätigt.

3. Wetterinformationsdienst

Ein Webdienst, der Wetterinformationen für einen bestimmten Standort bereitstellt. Der Client sendet eine SOAP-Anfrage mit dem gewünschten Standort und der Server antwortet mit einer SOAP-Nachricht, die Details wie Temperatur, Luftfeuchtigkeit und Vorhersage enthält.

4. Kundenmanagementsystem

Ein Webdienst, der Kundeninformationen für eine E-Commerce-Plattform verarbeitet. Der Client kann SOAP-Anfragen senden, um Kundendaten zu erstellen, zu aktualisieren oder abzurufen. Der Server verarbeitet die Anfragen und sendet SOAP-Antworten mit dem entsprechenden Status oder den angeforderten Kundeninformationen.

In jedem Anwendungsfall handelt es sich bei den SOAP-Anfragen und -Antworten um strukturierte XML-Nachrichten, die zwischen dem Client und dem Server ausgetauscht werden. Das folgende Beispiel erklärt es besser.

SOAP-Beispiel

Hier ist ein Code-Snippet-Beispiel einer Banking-App, die SOAP verwendet, um mit einem Server zur Kontoverwaltung zu interagieren.

In diesem Beispiel handelt es sich bei der SOAP-Anfrage um einen Geldtransfervorgang. Die Anfrage umfasst das Quellkonto, das Zielkonto und den Überweisungsbetrag. Die SOAP-Antwort enthält die Transaktions-ID und den Status der Übertragung.

REST-Anwendungsfälle

Hier sind einige Anwendungsfälle von REST-APIs, die HTTP und JSON nutzen.

1. Social-Media-Plattform

Mit der REST-API für eine Social-Media-Plattform können Benutzer Beiträge, Kommentare und Benutzerprofile erstellen, abrufen, aktualisieren und löschen. Clients können HTTP-Methoden wie POST, GET, PUT und DELETE verwenden, um mit den API-Endpunkten zu interagieren. Beispielsweise kann ein Client eine POST-Anfrage senden, um einen neuen Beitrag zu erstellen, eine GET-Anfrage, um eine Liste von Beiträgen abzurufen, oder eine PUT-Anfrage, um die Profilinformationen eines Benutzers zu aktualisieren.

2. E-Commerce-Shop

Mithilfe einer RESTful-API für einen E-Commerce-Shop können Kunden Produkte durchsuchen, Artikel zu einem Warenkorb hinzufügen, Bestellungen aufgeben und den Bestellverlauf abrufen. Clients können HTTP-Methoden verwenden, um Aktionen wie GET zum Abrufen von Produktinformationen, POST zum Hinzufügen von Artikeln zum Warenkorb und PUT oder DELETE zum Aktualisieren oder Entfernen von Artikeln aus dem Warenkorb auszuführen.

3. Finanzdienstleistung

Eine RESTful-API für einen Finanzdienstleister ermöglicht es Kunden, verschiedene Vorgänge wie Kontostandabfragen, Geldtransfers und den Abruf des Transaktionsverlaufs durchzuführen. Kunden können HTTP-Methoden wie GET zum Abrufen von Kontoinformationen, POST zum Initiieren einer Geldüberweisung und GET zum Abrufen des Transaktionsverlaufs verwenden.

4. Kartierungs- und Geolokalisierungsdienst

Bei Verwendung für Kartierungs- und Geolokalisierungsdienste kann eine REST-API Funktionen für die Adresssuche, Geokodierung und Routing bereitstellen. Clients können Anfragen mit Parametern wie Adressen, Koordinaten oder bestimmten Routen an die API-Endpunkte senden, um die gewünschten Informationen zu erhalten. Die API antwortet mit den entsprechenden Daten in einem Format wie JSON oder XML.

REST-Beispiel

Betrachten wir nun eine Filmdatenbank-API, die REST zum Abrufen von Filminformationen verwendet.

Im obigen Beispiel dient die REST-Anfrage dazu, Informationen zu einem bestimmten Film mit der ID „123456“ abzurufen. Die REST-Antwort hat den Statuscode 200 (OK) und liegt im JSON-Format vor und enthält Details wie Filmtitel, Jahr, Regisseur, Genre und Bewertung.

Die obigen Beispiele verdeutlichen die Unterschiede in der Art und Weise, wie Anfragen und Antworten ausgetauscht werden, sie können jedoch auch dieselben Anwendungsfälle erfüllen. Mit anderen Worten: Die oben genannten REST-APIs könnten als SOAP-Dienste implementiert werden und umgekehrt.

Für eine bestimmte REST-API kann für jede CRUD-Operation eine SOAP-Operation definiert werden und alle Ressourcenparameter können in XML-Elemente innerhalb des SOAP-Körpers übersetzt werden. Die oben genannten SOAP-Beispiele können auch als REST-APIs implementiert werden. Ein Ansatz besteht darin, verschiedene SOAP-Vorgänge verschiedenen HTTP-Verben zuzuordnen. Das Beispiel eines Kundenverwaltungssystems funktioniert hierfür gut, da es über CRUD-basierte SOAP-Operationen verfügt, die sauber den entsprechenden HTTP-Verben zugeordnet werden können.

Der andere Ansatz besteht darin, verschiedene SOAP-Vorgänge verschiedenen Ressourcenpfaden zuzuordnen. Das Währungsumrechnungsbeispiel könnte REST-fähig gemacht werden, indem der Währungstyp im Ressourcen-URI dargestellt wird. Dann können Sie die Darstellung der gewünschten Währung buchstäblich „GET“ erhalten, wobei die Umrechnungsparameter als Abfrageparameter wie „/conversion/dollar?fromAmount=5&fromType=pesos“ übermittelt werden, was das Ergebnis als JSON-Nummer zurückgeben könnte.

Vergleich von SOAP und REST für API-Tests

REST und SOAP bringen ihre eigenen einzigartigen Kompromisse und Herausforderungen mit sich, insbesondere im Hinblick auf Tests. Um eine API zu testen, müssen Sie in der Lage sein, Clients zu erstellen, Eingabedaten zu senden und anschließend die zurückgegebene Ausgabe anzuzeigen und zu validieren. Um einen umfassenden Vergleich zwischen den beiden zu ziehen, schauen wir uns zunächst SOAP und REST für API-Tests wie folgt an.

Testbarkeit

SOAP-APIs sind komplexer und erfordern spezielle Tools, die das SOAP-Protokoll verstehen. Das Testen von SOAP-basierten Diensten umfasst das Parsen von XML, die Interpretation von WSDL- und WS-*-Spezifikationen und die Handhabung von SOAP-Umschlagstrukturen. Glücklicherweise bietet ein hochentwickeltes SOAP-Testtool wie Parasoft SOAtest Funktionen wie die automatisierte Testgenerierung, die diese Komplexität vereinfacht und SOAP-API-Tests schneller und effizienter macht.

Andererseits folgen REST-APIs einem einfacheren Design und nutzen Standard-HTTP-Methoden und Datenformate wie JSON. Diese Einfachheit macht REST-APIs für Tests zugänglicher. Parasoft SOAtest bietet außerdem hervorragende Unterstützung für REST-API-Tests, sodass Tester problemlos HTTP-Anfragen erstellen, Antworten validieren und Funktions- und Integrationstests durchführen können.

Test Ausführung

Beim SOAP-API-Testen werden Testfälle ausgeführt, die über SOAP-Umschläge mit der API interagieren. Dies erfordert die Handhabung von XML-Parsing, SOAP-Headern und die Einhaltung des SOAP-Protokolls und verschiedener WS-*-Standards. SOAP-Dienste können auch über andere Transportprotokolle als HTTP implementiert werden. Auch wenn dies viel zu komplex klingt, ermöglichen die umfangreichen Funktionen von SOAtest mit voller Unterstützung für viele Transportprotokolle und komplexe WS-* SOAP-Spezifikationen die Automatisierung dieser Prozesse.

REST-API-Tests ermöglichen aufgrund ihrer Vereinfachung eine schnellere Testausführung und erleichtern die Überprüfung des Verhaltens und der Reaktion der API. REST-APIs eignen sich auch gut für die Automatisierung, da gängige Test-Frameworks häufig robuste Bibliotheken zum Erstellen von HTTP-Anfragen und -Behauptungen bereitstellen. Dies ermöglicht die Erstellung automatisierter Testsuiten, die problemlos in Pipelines der kontinuierlichen Integration (CI/CD) integriert werden können.

Testfallgenerierung

SOAP-APIs basieren auf WSDL-Spezifikationen (Web Service Description Language), um ihre Vorgänge, Datentypen und Nachrichtenstrukturen zu definieren. Diese formale Spezifikation erleichtert die Generierung von Testfällen auf Basis des definierten Vertrags. Während einige Tools bei der Testfallgenerierung hilfreich sein können, erstellt Parasoft SOAtest anspruchsvolle Clients, die den von der WSDL beschriebenen XML-Schematypen und WS-*-Anforderungen korrekt entsprechen und so den manuellen Aufwand für die Erstellung von Testszenarien reduzieren.

REST-APIs werden oft durch ein formales Dokument wie eine OpenAPI-Definition beschrieben. Servicedefinitionsdokumente können je nach Anzahl der Ressourcen, Parameter und JSON-Schematypen umfangreich oder komplex sein. Parasoft SOAtest erstellt anspruchsvolle Clients, die die von jeder Ressource und HTTP-Methode erwarteten Parameter- und JSON-Schematypen korrekt einhalten. Allerdings fehlt REST-APIs manchmal eine formale Spezifikation wie OpenAPI, was die Testfallgenerierung schwieriger machen kann.

Tester stützen sich bei der Definition ihrer Testszenarien häufig auf zuvor aufgezeichnete Verkehrsmeldungen. Während dies normalerweise einen höheren manuellen Aufwand mit sich bringt, automatisiert der Smart API Test Generator von Parasoft SOAtest die Testerstellung, indem er API-Aufrufe überwacht und künstliche Intelligenz (KI) nutzt, um Testszenarien automatisch zu erstellen und zu konfigurieren.

Dennoch ist es wichtig zu beachten, dass die Wahl zwischen SOAP und REST für API-Tests hängt von den spezifischen Anforderungen des Projekts ab. Die strengen Vertrags- und Validierungsfunktionen von SOAP eignen sich für Anwendungen auf Unternehmensebene, die Standardisierung und Interoperabilität erfordern. Andererseits zeichnet sich REST durch Einfachheit, Flexibilität und einfache Testbarkeit aus, was es zur bevorzugten Wahl für viele moderne Webdienste macht. Dennoch profitiert jede Option, die für Ihr Projekt am besten geeignet ist, von der API-Testautomatisierung von Parasoft SOAtest.

Positiver Vergleich

SEIFE. Ein WSDL-Dokument kann eine vollständige Beschreibung eines SOAP-Dienstes einschließlich seiner Sicherheitsanforderungen enthalten. Es stehen verschiedene kommerzielle und Open Source-Tools zur Verfügung, die WSDL-Dokumente verwenden können, um automatisch Clients zum Testen von SOAP-Endpunkten zu erstellen. Ein einfaches Beispiel ist das von Microsoft WCF-Testclient Anwendung.

SICH AUSRUHEN. REST-APIs können auf ähnliche Weise ein Service-Definitionsdokument bereitstellen, das zur Erstellung von Testclients verwendet werden kann. Für OpenAPI Swagger-Benutzeroberfläche bietet eine einfache Weboberfläche zum „Ausprobieren“ jeder einzelnen von der API bereitgestellten Operation.

Kritischer Vergleich

SOAP-Dienste kann unter Verwendung anderer Protokolle als HTTP implementiert werden, wobei die Kommunikation möglicherweise eine bestimmte Messaging-Schnittstelle wie JMS erfordert. Verschiedene WS-*-Protokolle sind komplex. Kostenlose und Open-Source-Tools haben Einschränkungen und fehlende Unterstützung für alle Transport- und WS-*-Protokolle. Parasoft SOAtest hilft jedoch bei der Lösung dieses Problems, da es umfassende Unterstützung für SOAP und verwandte Protokolle bietet.

REST-Dienste haben nicht unbedingt Dienstdefinitionen. Das manuelle Erstellen von Clients kann schwierig und mühsam sein, da die richtige Abfolge von API-Aufrufen bestimmt werden muss, die aneinandergereiht werden müssen, um die gewünschten Szenarien zu erstellen. Jedoch, Parasoft SOAtest hilft, dies zu lösen. SOAtests sind nicht nur in der Lage, Testclients aus verschiedenen Service-Definitionsformaten zu erstellen Intelligenter API-Testgenerator Automatisiert die Erstellung von API-Tests durch Überwachung von API-Aufrufen und Verwendung von KI zur automatischen Erstellung und Konfiguration von Testszenarien.

Schwirrt dir schon der Kopf? Lassen Sie Parasoft helfen. Reduzieren Sie Kosten, Zeit und Komplexität beim Testen von Serviceschnittstellen mit der vollständigen End-to-End-API-Testlösung Parasoft SOAtest.