Microservices als Alternative zu monolithischen Applikationen liegen voll im Trend. Kein Wunder, denn auf Microservices basierende Architekturen vereinfachen die Skalierbarkeit und verringern die Entwicklungszeit von Anwendungen, ermöglichen Innovationen und verkürzen die Markteinführungszeit für neue Funktionen. In der Regel kommen Microservices in einer Cloud zum Einsatz und bedienen sich dabei eigener oder externer APIs. In diesem Zusammenhang spielt die zunehmende Verbreitung von Cloud eine entscheidende Rolle und macht die Bedeutung von Web-APIs größer.
Außerdem: Zahlreiche Standards, beispielsweise in der Reisebranche, in der Automobilindustrie und im Gesundheitswesen, sowie regulatorische Auflagen wie die Zahlungsdienstrichtlinie PSD2 (siehe Glossar unten) „befeuern“ das Thema zusätzlich. So regelt PSD2 beispielsweise, welche Schnittstellen beim Online-Bezahlen verwendet werden dürfen.
Bei der Entwicklung und dem Einsatz von APIs handelt es sich jedoch nicht nur um einen Aspekt der IT. Das gesamte Business ist davon betroffen und alle „Akteure“ eines Unternehmens sollten deshalb darin involviert sein. Schließlich besitzt das Ganze einen hohen „Monetization“-Faktor: Mit selbstentwickelten Services lässt sich schlichtweg gut Geld verdienen. Nicht nur Global Playern, sondern auch kleinen und mittleren Unternehmen bietet sich dadurch die Chance, ihr bisheriges Geschäftsfeld zu erweitern. Last but not least ist die allgemeine Digitalisierung von Wirtschaft und Gesellschaft ein starker Wachstumstreiber in Sachen API. Die elektronische Kommunikation zwischen Unternehmen, Behörden und Bürgern bzw. Verbrauchern setzt sich auf breiter Front durch – und dafür benötigt man eben entsprechende Schnittstellen.
Lesedauer: 8 Min
Als Folge eines Unwetters ist die Schadensregulierung eines Versicherers mit zahlreichen Regressforderungen seiner Kunden konfrontiert. Um zu prüfen, ob jede Reklamation auch berechtigt ist und um einen möglichen Versicherungsbetrug auszuschließen, benötigt der Sachbearbeiter detaillierte Informationen über Zeit und Ort des Unwetters. Wann und wo trat der Hagel mit welcher Intensität auf? Lag der Wohnort des Versicherten zum reklamierten Zeitpunkt tatsächlich im Einzugsbereich des Unwetters? Kann der geschilderte Schaden am Gebäude oder Fahrzeug wirklich durch das konkrete Unwetter verursacht worden sein oder handelt es sich möglicherweise um einen älteren Schaden?
Dafür nutzt der Sachbearbeiter in der Schadensregulierung in der Regel einen externen Wetterdienst, dessen App problemlos über eine API an die IT-Infrastruktur des Versicherers angebunden ist. So kann der Mitarbeiter direkt in seiner Fachanwendung detaillierte Wetterberichte für eine bestimmte Region, einen Landkreis oder einen Ort zum Tag X abfragen. Dabei lässt sich tief „verzweigen“ bis auf Straßen- und Uhrzeitebene. Diese Informationen sind dann die Entscheidungsgrundlage für Annahme oder Ablehnung der Regressforderung. Der Vorteil besteht nun darin, dass durch die Integration einer externen Spezial-Applikation in die vorhandenen Prozesse eine deutlich schnellere Schadensabwicklung möglich ist.
Compart, als international agierender Hersteller von Software für die Omnichannel-Kundenkommunikation, bietet auf seiner Website ein Tool zum Erzeugen von Barcodes an. Über eine von Compart zur Verfügung gestellte API können Interessenten einen beliebigen Barcode generieren und diesen in das eigene System für die Weiterverarbeitung übernehmen, beispielsweise für der Dokumentenerstellung. Der Anwender registriert sich auf der Homepage von Compart, bekommt einen Zugangscode und kann dann direkt in der Fachanwendung die Web-API des Barcode-Generators ansteuern. Statt also in eine eigene separate Software zur Barcode-Erzeugung zu investieren, nutzt der Interessent direkt den API-Dienst von Compart.
Tatsache ist: Es gibt eine generell hohe Motivation für den Einsatz von Web-APIs. Nicht nur, dass damit wertvolle Ressourcen geschont werden (keine eigene Softwareentwicklung notwendig) und sich bestehende Produkte oder Dienstleistungen schnell und unkompliziert erweitern lassen. Web-APIs ermöglichen darüber hinaus die Interoperabilität zwischen externen und internen Systemen und eröffnen Unternehmen dadurch Chancen für neue Geschäftsmodelle und Partnerschaften mit anderen Firmen.
Man denke beispielsweise an die Kooperation zwischen einer Krankenversicherung und einem medizinischen Institut für Infektionskrankheiten. Die vom Institut zur Verfügung gestellten Informationen könnten dem Versicherer helfen, Gefahrensituationen schneller zu erkennen, zu bewerten und gemeinsam mit Health-Anbietern frühzeitig wirkungsvolle Therapien für den Versicherten zu entwickeln. Auch das könnte man über einen entsprechenden Web-API-Dienst umsetzen.
80 Prozent aller Web-API, die heute zum Einsatz kommen, basieren auf der REST-Architektur (siehe Glossar). Dabei handelt es sich strenggenommen nicht um ein Protokoll, sondern um einen Ansatz, wie man mittels HTTP bestimmte Einschränkungen (Constraints) sowie die Interaktion zwischen virtuellen Maschinen, Systemen und Anwendungen beschreiben kann. Das Interessante dabei ist, dass HTTP nicht für APIs entwickelt wurde, sondern für Webseiten. Warum also ist REST so stark verbreitet?
Zum einen ist diese Architektur einfach zu verstehen und lässt sich viel schneller umsetzen als andere, beispielsweise das komplexe SOAP-Protokoll, das von 2000 bis 2010 besonders stark verbreitet war und noch heute im Einsatz ist. SOAP wurde ausschließlich für die Interaktion zwischen Servern und nicht für die Client-Server-Kommunikation entwickelt. Zudem ist SOAP sehr „mächtig“ und verlangt schon ein tiefes Programmier-Know-how. Im Gegensatz dazu ist REST eher „schlank“ gehalten und für jeden, der einigermaßen HTTP versteht, leicht zu begreifen bzw. in der Praxis umzusetzen.
Trotzdem besitzt die REST-Architektur einige Einschränkungen. Da es sich hier nicht um einen weltweit gültigen Standard handelt, ermöglicht sie eine freie Auslegung in der Anwendung und Entwicklung – frei nach dem Motto: Jeder kann machen, wie er denkt, dass es richtig ist. Entsprechend hoch ist die Vielzahl an unterschiedlichen Umsetzungen.
Genau da liegt das Problem: Die Anwendung von REST-API mag zwar einfach sein. Doch die „saubere“ Implementierung von REST-APIs – gutes Design, detaillierte und verständliche Dokumentation, stringentes Management – stellt eine große, organisatorische Herausforderung dar. Zudem sind CRUD-Operationen für Datenbanken und statische Datenspeicher bei REST eher beschränkt; und für die Umsetzung von Anforderungen wie IoT, KI und Bots, die andere Arten von APIs benötigen, ist die REST-Architektur nicht ideal.
Eine weitere Herausforderung bei REST besteht darin, dass man immer die komplette Ressource anfordern muss – auch, wenn man nur eine einzige, kleine Eigenschaft (Attribut) benötigt. Dieses „Overfetching“ ist in manchen Fällen ein gravierender Nachteil von REST-APIs.
Natürlich existieren mit gRPC, RSocket, W3C SPARQL, GraphQL, JSON:API, OASIS Odata ernstzunehmende Alternativen. So spiegelt beispielsweise das von Google entwickelte Protokoll gRPC gewissermaßen die moderne Welt der API-Kommunikation wider. Das auch außerhalb von Google zum Einsatz kommende Protokoll ist ein leichtgewichtigerer Ansatz als das mächtige SOAP und sehr effizient bei der Verarbeitung von Daten. Vor allem in der Kommunikation zwischen Systemen innerhalb eines Unternehmens stößt man in der Praxis auf gRPC. Dabei wird hauptsächlich über einen Binärtransport kommuniziert (mehr zu gRPC siehe Glossar unten). Kurz: Bei der Entwicklung einer API-Strategie sollte man nicht von vornherein ausschließlich auf REST setzen, sondern auch Alternativen prüfen.
Inzwischen haben viele Unternehmen und Organisationen sogenannte Guidelines für den Umgang und den Einsatz von APIs veröffentlicht. Diese Leitfäden beschreiben zum Beispiel, wie die APIs gesichert sein sollten, welche Namenskonventionen gelten, welche HTTP-Headers unterstützt werden, wie Fehlermeldungen auszusehen haben und vieles mehr. Sie sind sowohl für die Programmierer im jeweiligen Unternehmen als auch für externe Anwender gedacht, um regelkonform API-Services zu entwickeln und zu nutzen.
Wer beispielsweise die Suchplattform von Zalando in sein Unternehmensportal integrieren will, muss die API-Guideline des Online-Versandhändlers genau kennen und für die Umsetzung berücksichtigen. Da viele Firmen ihre Regelwerke öffentlich zur Verfügung stellen, ist es für Unternehmen, die gerade begonnen haben, sich mit dem Thema API zu beschäftigen, eine wichtige Quelle. Man könnte auch sagen: Sie profitieren von diesem unternehmensübergreifenden Know-how-Transfer insofern, als dass sie von den Erfahrungen der „alten Hasen“ lernen und sich von erfolgreich durchgeführten API-Projekten inspirieren lassen können. Eine aktuelle Übersicht findet man unter http://apistylebook.com/design/guidelines/.
Fest steht: APIs als geschäftskritische Faktoren bedürfen eines strikten Managements (Governance). Noch nie war das technologische „Ökosystem“ so reichhaltig wie heute. Schnell kann man hier den Überblick verlieren. Daher ist eine klare API-Strategie ungemein wichtig. Dabei sollte man im Hinterkopf behalten, dass REST nicht alle Probleme löst. Es gibt auch andere gute Architekturen bzw. Ansätze. Entscheidend sind letzten Endes die spezifischen Unternehmensanforderungen (Was will man durch die Etablierung einer API-Economy erreichen?) und eine ausgiebige Analyse der vorhandenen Struktur. Zu empfehlen ist in diesem Zusammenhang, bei der Nutzung von externen API-Services nicht nur auf einen Anbieter zu setzen bzw. den Einfluss eines externen Dienstleisters auf die eigene Infrastruktur möglichst gering zu halten.
Firmen, die sich ausschließlich auf einen API-Dienstleister konzentrieren, laufen Gefahr, durch plötzliche Marktveränderungen von einem Tag auf den anderen keinen Zugriff mehr auf die Services zu bekommen; beispielsweise dann, wenn Anbieter und Abnehmer auf Grund der Ähnlichkeit ihrer Geschäftsfelder plötzlich zu Wettbewerbern werden oder wenn es Rechtsstreitigkeiten gibt.
Noch gut in Erinnerung ist der Fall PeopleLinx (jetzt Frontline Selling). Gegründet von ehemaligen Mitarbeitern der Businessplattform LinkedIn, wurde dem Unternehmen von LinkedIn „über Nacht“ der Zugriff auf dessen API-Dienste verweigert. Der Vorwurf: PeopleLinx habe auf LinkedIn unerlaubt Daten abgegriffen und diese anderen Unternehmen zur Verfügung gestellt. Damit habe man gegen vertragliche Bestimmungen über die Verwendung der zur Verfügung gestellten APIs verstoßen, so LinkedIn. Plötzlich stand PeopleLinx ohne die dringend benötigten API-Services da.
Übrigens – Verletzungen des Datenschutzes sind nicht selten der Grund dafür, dass Kooperationen innerhalb einer API-Economy in die Brüche gehen. Vielen noch gut in Erinnerung ist der Cambridge-Analytica-Skandal. Das von der britischen SCL Group gegründete Analyse-Unternehmen hatte bei Facebook unerlaubt Daten abgegriffen und diese für gezielte Marketingbotschaften zugunsten des Brexit in Großbritannien genutzt. Möglich war das, weil es Schwachstellen in den von Facebook zur Verfügung gestellten APIs gab.
Die geschilderten Beispiele machen gleich mehrere Aspekte deutlich. Zum einen sollte man sich von externen API-Diensten nicht zu stark abhängig machen und erst recht nicht nur „auf ein Pferd setzen“. Lieber die Services von unterschiedlichen Anbietern nutzen und frühzeitig einen Notfallplan entwickeln: Was tun, wenn man – aus welchen Gründen auch immer – keinen Zugriff mehr auf einen API-Dienst hat? Welche Alternativen gibt es?
Zum anderen gilt es, vertraglich genau zu regeln, wer wofür und in welchem Umfang den API-Dienst nutzen darf, um – wie im Falle von CA - keine „bösen Überraschungen“ zu erleben.
Die Frage, ob man auf große etablierte API-Anbieter wie Amazon, Google oder Microsoft setzen soll oder auf Spezialisten („Best of Breed“), auch wenn diese Nischenplayer sind, dafür aber mit einem herausragenden Produkt, ist schwer zu beantworten. Je nach Business Case und Anforderungen fällt die Antwort unterschiedlich aus. Heute gibt es diverse Plattformen, die eine Vielzahl an API-Diensten verschiedener Dienstleister anbieten, beispielsweise Rapid API (www.rapidapi.com).
Gerade in der Kundenkommunikation spielen solche Tools eine immer wichtigere Rolle; beispielsweise dann, wenn man die eingehenden Nachrichten – ob nun digital oder als klassisches Papierdokument – daraufhin untersuchen will, in welchem „Ton“ diese gehalten sind. Droht der Kunde etwa mit Anwalt, setzt er Fristen oder baut er eine sprachliche „Drohkulisse“ auf? Die Analyse und die daraus resultierenden Schlussfolgerungen sind wichtig für eine Priorisierung der einzelnen Kommunikationsvorgänge und eine dementsprechend zügige fallabschließende Vorgangsbearbeitung. Aber auch für die Klassifizierung und das Tracking von Dokumenten generell lassen sich solche API-Dienste nutzen.
Oder: Mittels „Language Scoring“ kann man den Schwierigkeitsgrad eines Textes analysieren. Wie verständlich ist der Inhalt für die jeweilige Zielgruppe? Das ist natürlich abhängig vom beruflichen und privaten Hintergrund (Muttersprachler, Bildungsgrad, Allgemeinverständnis). Ist ein White Paper beispielsweise zu wissenschaftlich (der Scoring-Wert also sehr hoch), ließen sich Sätze und Textpassagen umformulieren, die Satzstruktur vereinfachen oder weniger Fremdwörter verwenden. Es geht hier also um zielgruppengerechten Content.
Aber auch die „Darreichungsform“ von Inhalten spielt in der Kundenkommunikation eine entscheidende Rolle. Man könnte auch sagen: Die Erstellung von Dokumenten muss heute so erfolgen, dass sie – entsprechend dem Wunsch des Empfängers – auf jedem analogen und digitalen Medium per se versendet bzw. dargestellt werden können. Dazu muss sich die Dokumentenerstellung vom sogenannten A4-Paradigma lösen.
So bietet beispielsweise Compart mit DocBridge® Impress eine leistungsstarke Lösung für das seiten- und geräteunabhängige Design von Dokumenten an – und zwar nicht nur als Client-Software, sondern auch als Container im Rahmen von Kubernetes innerhalb einer Cloud. DocBridge® Impress lässt sich dabei über eine API an die Infrastruktur des Kunden anbinden.
DocBridge® Impress ist eine skalierbare, plattformunabhängige und cloudfähige Software für das seiten- und geräteunabhängige Design von Dokumenten, die sich auch von Anwendern ohne profundes IT-Know-how einfach bedienen lässt. Die mit DocBridge® Impress erstellten Dokumente sind omnichannel-fähig und barrierefrei gemäß PDF/UA und WCAG. Mit DocBridge® Impress erhalten Benutzer einen schnellen Zugang zu allen modernen, digitalen Kommunikationskanälen.
Mit der Composition-Lösung lassen sich Dokumente erstellen und auf allen relevanten Kanälen versenden und auf unterschiedlichen Medien anzeigen: als gedruckte Seiten, als PDF im E-Mail-Anhang, als responsive HTML Seite im Webbrowser und auf dem Smartphone/Tablet, über Messenger-Dienste etc. Jedes neue Dokument braucht nur einmal generiert zu werden und steht ohne größeren Aufwand für alle Medien zur Verfügung. DocBridge® Impress bedeutet einen Paradigmenwechsel im Dokumentendesign: Die Erstellung erfolgt unabhängig von einer vorgegebenen Seitengröße und basiert auf offenen Standards.
Weitere Features sind:
Zum 13. Januar 2018 wurde in Deutschland die neue europäische Zahlungsdienstrichtlinie PSD2 (Payment Services Directive2) in nationales Recht umgesetzt. Mit dem Gesetz zum Inkrafttreten der Zweiten Zahlungsdienstrichtlinie (Zahlungsdienstumsetzungsgesetz - ZDUG) wurden die aufsichtsrechtlichen Bestimmungen im Zahlungsdienstaufsichtsgesetz (ZAG) und die zivilrechtlichen Vorgaben im Bürgerlichen Gesetzbuch (BGB) berücksichtigt. Zudem waren Folgeänderungen in weiteren Gesetzen (z. B. Kreditwesengesetz) erforderlich.
Die PSD2 ist eine EU-Richtlinie zur Regulierung von Zahlungsdiensten und Zahlungsdienstleistern mit dem Ziel,
Die PSD2 gilt für Zahlungen in EU/EWR-Währungen zwischen im EU/EWR-Raum ansässigen Zahlungsdienstleistern. Darüber hinaus findet sie teilweise auch Anwendung auf Zahlungen in Nicht-EU/EWR-Währungen (z.B. US-Dollar oder britisches Pfund) sowie wenn ein Zahlungsdienstleister außerhalb des EU/EWR-Raums ansässig ist (z.B. Schweiz oder USA).
Die neue Richtlinie zieht Änderungen im Verhältnis zwischen Verbraucher, Händler und Zahlungsdienstleister nach sich. So gibt die PSD2 den Zahlern das Recht, einen Drittdienstleister zu nutzen und verpflichtet die kontoführenden Zahlungsdienstleister, den Drittdienstleistern künftig eine (eigene) Schnittstelle zur Verfügung zu stellen, über die Überweisungen (z. B. an den Internethändler) ausgelöst, Kontoinformationen heruntergeladen oder die Deckung von Kartenverfügungen abgefragt werden können.
Mehr Informationen unter www.bundesbank.de/de/aufgaben/unbarer-zahlungsverkehr/psd2
Quelle: Deutsche Bundesbank
Die Kommunikationskanäle nehmen nicht nur zu, sondern werden technisch auch anspruchsvoller. Wenn beispielsweise Audio- und Videonachrichten als Medien immer wichtiger werden, dann muss man sich auch darüber Gedanken machen, wie man daraus „maschinenlesbare“ Daten erzeugen kann, damit sie automatisiert verarbeitet werden können. Beispiel „Text-to-Speech“: Auch in diesem Fall stellt sich die Frage, ob es für ein Unternehmen sinnvoll ist, eine eigene Software für Spracherkennung zu entwickeln oder ob es nicht besser wäre, auf eine „gut trainierte“, selbstlernende Applikation von externen Anbietern zurückzugreifen, die sich in der Praxis bewährt hat und die auf Grund ihrer Verbreitung und ihrer Performance (schnelle Verarbeitung großer, komplexer Datenmengen) auch ein hohes Maß an Zuverlässigkeit besitzt. Sprachassistenten wie Alexa, Siri oder Bixby, aber auch etliche Chatbots sind unter anderem deshalb so verbreitet, weil sie mittlerweile auf Grund sehr ausgefeilter KI-Mechanismen auch syntaktisch und semantisch sehr anspruchsvolle Sprachnachrichten detailliert analysieren können. Deshalb werden früher oder später Unternehmen auch solche externen Services über APIs in ihre „Kommunikationslandschaft“ holen.
Representational State Transfer (REST oder auch ReST) bezeichnet ein Programmierparadigma für verteilte Systeme, insbesondere für Webservices. REST ist eine Abstraktion der Struktur und des Verhaltens des World Wide Web. REST hat das Ziel, einen Architekturstil zu schaffen, der die Anforderungen des modernen Web besser darstellt. Dabei unterscheidet sich REST vor allem in der Forderung nach einer einheitlichen Schnittstelle von Architekturansätzen.
REST fokussiert die Maschine-zu-Maschine-Kommunikation und stellt eine Alternative zu ähnlichen Verfahren wie SOAP und WSDL sowie dem verwandten Verfahren RPC dar. Anders als bei ähnlichen Architekturen kodiert REST keine Methodeninformation in den URI (Uniform Resource Identifier - deutsch: Identifizierung von abstrakten oder physischen Ressourcen wie Webseiten, sonstigen Dateien, Aufruf von Webservices oder E-Mail-Empfängern), da der URI Ort und Namen der Ressource angibt, nicht aber die Funktionalität, die der Web-Dienst zur entsprechenden Ressource anbietet.
Der Vorteil von REST liegt darin, dass im World Wide Web bereits ein Großteil der für REST notwendigen Infrastruktur (z. B. Web- und Application-Server, HTTP-fähige Clients, HTML- und XML-Parser, Sicherheitsmechanismen) vorhanden ist und viele Web-Dienste per se REST-konform sind. Eine Ressource kann dabei über verschiedene Medientypen dargestellt werden, auch Repräsentation der Ressource genannt. So ist beispielsweise ein Online-Dienst, der lediglich unveränderte Seiteninhalte nach dem Internetstandard HTTP anbietet, bereits REST-tauglich.
Dynamisch erzeugte Seiten dagegen folgen diesem Prinzip oft nicht. So bieten beispielsweise Nachrichtenseiten sich ständig ändernde Informationen in sowohl unterschiedlichem Format als auch Inhalt an, die nur schwer automatisch verarbeitet werden können. Bliebe das Format unverändert, so wäre eine wichtige REST-Eigenschaft erfüllt.
SOAP (ursprünglich für Simple Object Access Protocol) ist ein Netzwerkprotokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure Calls durchgeführt werden können. SOAP ist ein industrieller Standard des World Wide Web Consortiums (W3C).
SOAP stützt sich auf XML zur Repräsentation der Daten und auf Internet-Protokolle der Transport- und Anwendungsschicht (vgl. TCP/IP-Referenzmodell) zur Übertragung der Nachrichten. Die gängigste Kombination ist SOAP über HTTP und TCP.
SOAP kann beispielsweise auch über SMTP oder JMS verwendet werden. Die mit der Nachricht übermittelten Nutzdaten müssen nicht zwingend in XML gesendet werden, andere Formate wie Base64 oder CSV sind auch möglich. Die Abkürzung SOAP wird offiziell ab Version 1.2 nicht mehr als Akronym gebraucht, da es erstens (subjektiv) keineswegs einfach (Simple) ist und zweitens nicht nur dem Zugriff auf Objekte (Object Access) dient.
Das Akronym CRUD umfasst die vier grundlegenden Operationen persistenter Speicher
Zum Verständnis: CRUD bezeicnet die grundlegenden Vorgänge, die in einem Daten-Repository ausgeführt werden müssen. Sie bearbeiten Datensätze oder Datenobjekte direkt. Abgesehen von diesen Vorgängen sind die Datensätze passive Einheiten. Normalerweise handelt es sich nur um Datenbanktabellen und Datensätze.
REST hingegen verarbeitet Ressourcendarstellungen, die jeweils durch eine URL gekennzeichnet sind. Dies sind normalerweise keine Datenobjekte, sondern komplexe Objektabstraktionen.
Eine Ressource kann beispielsweise ein Benutzerkommentar sein. Das bedeutet nicht nur einen Datensatz in einer 'Kommentar'-Tabelle, sondern auch die Beziehung zu der' Benutzer'-Ressource, dem Beitrag, an den der Kommentar angehängt ist, oder zu einem anderen Kommentar, auf den er reagiert.
Das Bearbeiten des Kommentars ist keine primitive Datenbankoperation, sondern kann erhebliche Nebenwirkungen haben, z. B. das Auslösen einer Warnung für das ursprüngliche Poster oder das Neuberechnen einiger spielähnlicher "Punkte" oder das Aktualisieren einiger "Follower-Streams".
Außerdem enthält eine Ressourcendarstellung Hypertext (überprüfen Sie das HATEOAS- Prinzip), sodass der Designer Beziehungen zwischen Ressourcen ausdrücken oder den REST-Client im Workflow einer Operation steuern kann.
Kurz gesagt, CRUD ist eine Menge primitiver Operationen (hauptsächlich für Datenbanken und statische Datenspeicher), während REST ein API-Stil auf sehr hoher Ebene ist (hauptsächlich für Webdienste und andere "Live" -Systeme).
Microservices sind ein architekturbezogener und organisatorischer Ansatz in der Softwareentwicklung, bei dem Software aus kleinen unabhängigen Diensten besteht, die über sorgfältig definierte APIs kommunizieren.
Auf Microservices basierende Architekturen vereinfachen die Skalierbarkeit und verringern die Entwicklungszeit von Anwendungen, ermöglichen Innovationen und verkürzen die Markteinführungszeit für neue Funktionen.
Quelle: Amazon AWS
gRPC (google Remote Procedure Calls) ist ein Protokoll zum Aufruf von Funktionen in verteilten Computersystemen. Es basiert auf den Standards HTTP/2 und Protocol Buffers.
Zur Funktionsweise:
Mittels einer Schnittstellenbeschreibungssprache (IDL) wird die Schnittstelle unabhängig von einer konkreten Programmiersprache spezifiziert. Über das Protocol-Buffer-Compilers 'protoc' (und eines Plugins für gRPC) können aus dieser Beschreibung Server- und Client-Codes, sogenannte Stubs, generiert werden.[1]
Auf der Serverseite wird der Stub üblicherweise durch Vererbung mit der eigentlichen Geschäftslogik ausgestattet. Auf Client-Seite ist der Stub in Verbindung mit einem Transport (der mit dem Server verbunden ist) verantwortlich für Aufrufe an den Server. gRPC unterstützt die Programmiersprachen C, C++, Java, Go, Node.js, Python, Ruby, Objective-C, PHP und C#
Quelle: Wikipedia
Open Data Protocol (Oasis) ist ein unter dem Open Specification Promise von Microsoft veröffentlichtes HTTP-basiertes Protokoll für den Datenzugriff zwischen kompatiblen Softwaresystemen, um in diesen CRUD-Operationen zu ermöglichen. Aufbauend auf älteren Protokollen wie ODBC und JDBC kann OData u. a. innerhalb von Cloud-Diensten (Azure), MySQL, Java und Rails eingebunden werden und ist in der Lage, in der Client-Server-Kommunikation eine einheitliche Semantik für den Datenaustausch zur Verfügung zu stellen.
Quelle: Wikipedia
SPARQL ist eine graphenbasierte Abfragesprache für RDF. Der Name ist ein rekursives Akronym für SPARQL Protocol And RDF Query Language.
Die RDF Data Access Working Group (DAWG) des World Wide Web Consortiums trieb die Entwicklung und Standardisierung von SPARQL voran. Im April 2006 wurde SPARQL als Candidate Recommendation anerkannt, im Oktober 2006 ist es jedoch wieder zum Working Draft zurückgestuft worden. Seit Juni 2007 lag SPARQL erneut als Candidate Recommendation des W3C vor. Am 15. Januar 2008 wurde SPARQL endgültig vom W3C als Recommendation freigegeben. Seit dem 21. März 2013 ist die W3C Recommendation für SPARQL 1.1 veröffentlicht worden. SPARQL ist der Nachfolger mehrerer Abfragesprachen (z. B. RDF Query Language, RDQL), die ebenfalls auf RDF-Daten zugreifen.
Quelle: Wikipedia
GraphQL ist eine Open-Source-Datenabfrage- und Manipulationssprache und ein Laufzeitsystem zum Beantworten von Abfragen mit vorhandenen Daten. GraphQL wurde 2012 von Facebook intern entwickelt und 2015 veröffentlicht. Am 7. November 2018 wurde das GraphQL-Projekt von Facebook in die neu gegründete GraphQL Foundation unter dem Dach der gemeinnützigen Linux Foundation ausgegliedert.
Es bietet eine effiziente und flexible Alternative zu SQL ganz im Sinne von REST und Ad-hoc-Webservice-Architekturen. Als eine zustandslose Abfragesprache ermöglicht es Clients, die genaue Struktur der benötigten Daten zu definieren. Durch diese Parametrisierung wird hier jedoch vermieden - ganz im Gegensatz zu vielen anderen implementierten REST-Schnittstellen -, bei jeder Anfrage unnötig große Datenmengen zu übermitteln.
GraphQL unterstützt das Lesen, Schreiben und Abonnieren von Datenänderungen (Echtzeit-Updates).
Zu den wichtigsten GraphQL-Clients gehören Apollo Client und Relay. GraphQL-Server sind für mehrere Sprachen verfügbar, einschließlich Haskell, JavaScript, Python, Ruby, Java, C#, Scala, Go, Elixir, Erlang, PHP, R und Clojure.
Am 9. Februar 2018 wurde die GraphQL Schema Definition Language (SDL) in die Spezifikation aufgenommen.
Quelle: Wikipedia
OpenAPI Specification (ehem. Swagger Specification) ist ein Standard zur Beschreibung von REST-konformen Programmierschnittstellen (API). Gefördert wird die Spezifikation von der OpenAPI Initiative. Diese verfolgt die Vision, im Sinne einer vernetzten Welt ein offenes und herstellerneutrales Beschreibungsformat für API-Dienste bereitzustellen. Das Projekt wird von der Linux Foundation unterstützt.
Die OpenAPI-Specification begann als Teil des Softwareprojekts Swagger, einem Open-Source-Framework für HTTP-Webservices. Im Jahr 2016 wurde sie ein eigenständiges Projekt, das von der OpenAPI Initiative verwaltet wird, zu deren Mitgliedern Unternehmen wie Atlassian, Google, IBM, Microsoft, PayPal und SAP zählen.
Swagger bietet eine Sammlung von Open-Source-Werkzeugen, um APIs zu entwickeln, die konform zur OpenAPI-Spezifikation sind:
Daneben existieren auch kostenpflichtige Werkzeuge:
Auch für verschiedene Entwicklungsumgebungen existieren Erweiterungen zur Unterstützung von OpenAPI.
JSON:API definiert einen Standard für REST-APIs. Wie GraphQL ermöglicht sie einem Client, mit einer Abfrage benötigte Daten anzufordern. Mobile Apps und Webanwendungen brauchen immer häufiger mehrere, teils dutzende Abfragen, bis sie alle benötigten Daten eingesammelt haben. Die Übertragung etlicher überschüssiger Daten und lange Ladezeiten sind die Folge. Auf die Anforderungen spezifischer Clients zugeschnittene Endpunkte markieren nur den mehr schlechten als rechten Versuch einer Lösung. Gleichzeitig erhöht der Wildwuchs unterschiedlicher Implementierungen die Einarbeitungszeit, den Dokumentationsaufwand und den Diskussionsbedarf für jede einzelne API.
Quelle: Heise online
Fazit: API-Services, sinnvoll eingesetzt, bieten Unternehmen vielfältige Möglichkeiten, ihre Prozesse in der Dokumentenerstellung noch mehr zu automatisieren und ihr Business insgesamt zu erweitern. Dafür sind einige Grundregeln zu beachten.
