Web-Service-API Contest – Teil 1 Web-Dienste und Service-orientierte Architektur

Web Services spielen mittlerweile eine große Rolle bei der Kommunikation zwischen IT-Systemen und -Komponenten. Denn serviceorientierte Architekturen, kurz SOA, bilden für nahezu alle professionellen Unternehmensanwendungen die Basis. Was bedeutet das?

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Confluent Germany GmbH

Windhoff Group

Es gibt unzählige Wege, Systeme in der IT miteinander zu koppeln: von der einfachen Kommunikation über Sockets, Shared Memory oder Named Pipes sowie Abstraktionen wie Remote Procedure Calls (RPC) bis hin zu proprietären Ansätzen wie DCOM, COBRA oder RMI.

In diesem Beitrag widmen wir uns der Frage, wie die APIs von Amazon AWS, Azure, Facebook, Twitter, Google, Ebay und Co (die Webseite ProgrammableWeb.com listet in ihrem API-Verzeichnis Stand heute über 5.000 Web-APIs) von „außen“ angesprochen bzw. angebunden werden. Dies ist nicht nur eine Frage des persönlichen Geschmacks, wobei zwischen „API-Protokollen“ wie SOAP, REST, JavaScript oder XML-RPC und „API-Datenformaten“ wie XML oder JSON zu unterscheiden ist.

Während sich die Verfechter von traditionellem SOAP (Simple Object Access Protocol) und neuem REST (Representational State Transfer) erbitterte Diskussionen liefern, hängt die Entscheidung in der Praxis oft von eher nüchternen Erwägungen ab. Beide Methoden haben nämlich ihre Vor- und Nachteile.

Hinter REST verbirgt sich allerdings tatsächlich etwas grundsätzlich Neues; und das könnte erhebliche Auswirkungen – wir wollen nicht gleich von einer Revolution sprechen – auf die künftigen Architekturen unserer IT-Systeme haben. Manch einer mag deshalb geneigt sein, schon vorab eine Lanze für REST zu brechen. Doch der Reihe nach.

Was sind Web-APIs?

Allgemein versteht man unter einer Web-API eine Anwendungsprogrammierschnittstelle (API) für einen Webserver oder einen Webbrowser. Das mit der Verwendung von Web-APIs einhergehende Entwicklungskonzept ist in der Regel auf die Client-Seite einer Webanwendung beschränkt, einschließlich der verwendeten Web-Frameworks. Es enthält keine Implementierungsdetails des Webservers oder Browsers wie SAPIs oder der Webbrowser-Engine-API, mit Ausnahme von Remote-Web-Anwendungen.

Web-Service-APIs Contest – Teil 2

Entstehung, Aufbau und Funktionsweise von SOAP

APIs gibt es sowohl für die Server- als auch für die Client-Seite. Dieser Beitrag behandelt die Server-seitigen APIs. Eine Server Side Web API ist eine Programmierschnittstelle, die aus einem oder mehreren öffentlich exponierten Endpunkten zu einem exakt definierten Request/Response-Messaging-System besteht, das typischerweise in JSON oder XML ausgedrückt wird und über das Web am häufigsten HTTP-basiert zum Einsatz kommt.

In diesem Zusammenhang sind zunächst einige Begrifflichkeiten zu klären:

• Bei so genannten Mashups handelt es sich um Web-Anwendungen, die mehrere Server-seitige Web-APIs kombiniert verwenden.

• Webhooks sind Server-seitige Web-APIs, die als Eingabe einen Uniform Resource Identifier (URI) verwenden, der so konzipiert ist, dass er wie eine entfernte benannte Pipe (Named Pipe) oder eine Art Callback verwendet wird. So fungiert der Server als Client, um über den bereitgestellten URI ein Ereignis auf einem anderen Server auszulösen, der dieses Ereignis behandelt, wodurch eine Art von Peer-to-Peer IPC (Interprozess-Kommunikation) entsteht.

• Endpoints stellen einen weiteren wichtigen Aspekt der Interaktion mit Server Side Web APIs dar. Sie geben an, wo Ressourcen liegen, auf die von Drittanbieter-Software zugegriffen werden kann. In der Regel erfolgt der Zugriff über einen URI, auf dem per HTTP entsprechende Anfragen eingehen und der auch angibt, von wem die Antwort erwartet wird. Endpunkte müssen statisch sein, da das korrekte Funktionieren von Software, die mit ihm interagiert, sonst nicht garantiert wäre. Ändert sich der Standort einer Ressource, ändert sich damit auch der Endpunkt und die Software würde nicht mehr funktionieren. Da API-Provider ihre Web-APIs aktualisieren möchten, haben viele ein Versionierungssystem im URI eingeführt, das auf einen Endpunkt verweist.

Was ist ein Web Service, was ist SOA?

Der Unterschied zwischen einer Web-Applikation und einem Web Service besteht darin, dass erstere von Menschen konsumiert wird und letzterer von einer Applikation.

Ein Web Service zeichnet sich dadurch aus, dass er im Internet global verfügbar und über HTTP erreichbar ist. Ferner setzen Web-Dienste auf Standards auf – darunter SOAP, UDDI (Universal Description, Discovery and Integration) sowie das unten erläuterte WDSL – und basieren auf XML. „Inhaltlich“ kann es sich bei einen Web Service um einen „selbstversorgenden“ Business-Task (d. h. der Task benötigt keine anderen Ressourcen), um einen vollwertigen Business-Prozess, eine Applikation oder eine selbst aktivierte Ressource handeln.

In Summe setzt sich eine komplette Service-orientierte Architektur (SOA) aus mehreren Konzepten zusammen. Diese müssen Unternehmen bei der Umsetzung berücksichtigen, wobei der Architekturstil oder das Programmiermodel nur zwei wesentliche Komponenten darstellen.

SOAP und REST – Traditionalist gegen Newcomer

Obwohl der Begriff „Web-API“ meist synonym für Web-Service verwendet wird, haben sich in den letzten Jahren viele Web-2.0-Anwendungen von ehemaligen SOAP-basierten Web-Services zu „Sammlungen von RESTful Web-Ressourcen“ gewandelt.

Solche RESTful-Web-APIs sind über Standard-Methoden (HTTP/S) von einer Vielzahl von HTTP-Clients einschließlich Browsern und mobilen Geräten zugänglich. Schon das ist auf dem ersten Blick ein Vorteil gegenüber Web-2.0-Services, unter anderem weil sie weniger ressourcenintensiv sind und damit in der Regel schneller laufen, insbesondere wenn sie JSON als Nachrichtenaustauschformat verwenden.

Web-Service-APIs Contest – Teil 3

Konzept, Aufbau und Funktionsweise von REST

Kommt nämlich JSON als Nachrichtenaustauschformat zum Einsatz, müssen im Einzelfall keine „XML-to-Programmiersprachen-Datenkonvertierungen“ (siehe weiter unten) durchgeführt werden, wie bei SOAP-basierten Service-APIs. Letztlich sind „Simple Object Access Protocol“ oder „Representational State Transfer“ aber nur zwei Antworten auf die gleiche einfache Frage: wie greift man schnell, einfach und effizient auf Web Services zu?

SOAP uns REST im Schnellcheck

• SOAP ist ein standardisiertes Web-Service-Zugangsprotokoll und – da schon viele Jahre im Gebrauch – entsprechend ausgereift.

• REST ist quasi der Neuling, auch wenn das relativ ist. REST ist vor allem angetreten, einige Probleme mit SOAP zu beheben und eine wirklich einfache Methode für den Zugriff auf Webservices bereitzustellen. SOAP ist nämlich im Gegensatz zu seinem ursprünglichen Akronym keineswegs simpel.

• Es gibt allerdings auch Situationen, in denen SOAP tatsächlich einfacher zu bedienen ist – denn auch REST hat manchmal so seine Probleme. So folgt SOAP einem strengeren Satz von Messaging-Pattern. Die Regeln in SOAP haben einen großen Teil dazu beigetragen, dass SOAP heute standardisiert ist.

• Da aber der REST-Architekturstil keinerlei Verarbeitung erfordert, lässt sich REST viel flexibler einsetzen.

• Auf der anderen Seite haben beide auch Ähnlichkeiten wie z. B. die Verwendung von HTTP.

Web-Service-APIs Contest – Teil 4

Anwendungsbeispiele mit REST

(ID:44607674)