Application Programming Interface (API)
API steht für Application Programming Interface. Eine API bezeichnet eine Programmierschnittstelle zwischen verschiedenen Anwendungen. Diese standardisierte Schnittstelle ermöglicht es Computersystemen, Daten einfach auszutauschen und miteinander zusammenzuarbeiten. Ähnlich wie Menschen dieselbe Sprache sprechen müssen, um sich zu verstehen, sorgt eine API dafür, dass die grundlegende Kommunikation zwischen Computersystemen geregelt ist. APIs bieten die Möglichkeit, schnell neue Funktionen zu Systemen hinzuzufügen und neue Systeme zu integrieren.
Was ist eine API-Schnittstelle?
In der heutigen digitalen Welt erledigen wir immer mehr online. Mit nur einem Klick auf dem Smartphone oder Laptop haben wir Zugang zu Nachrichten, sozialen Medien oder können beispielsweise eine Flugreise buchen. Nehmen wir das Beispiel einer Reisebuchung. Eine App oder Website kann nicht eigenständig arbeiten. Sie müssen dabei angeben, wohin Sie reisen möchten, mit wie vielen Personen und an welchem Datum. Um geeignete Flüge zu finden und anzuzeigen, benötigt die App Zugriff auf die Systeme verschiedener Fluggesellschaften.
Da es zahlreiche Fluggesellschaften und Reiseanwendungen gibt, wäre es unpraktisch, jedes Mal umfangreiche spezifische Anleitungen für individuelle Verbindungen zu erstellen. Hier kommen APIs ins Spiel. APIs ermöglichen es Reiseanwendungen, auf standardisierte Weise Informationen aus den Reservierungssystemen von Fluggesellschaften abzurufen. Ebenso verfügen Plattformen wie Booking.com über APIs, über die einzelne Vermieter ihre Unterkünfte in das System integrieren können. Ein weiteres Beispiel sind Krankenversicherungen, die über APIs Gesundheitseinrichtungen leicht anbinden. Banken bieten ebenfalls APIs an, um Kunden zu ermöglichen, ihre Konten mit Online-Buchhaltungsprogrammen zu verknüpfen.
APIs sind die standardisierten Verbindungen, die es ermöglichen, Computersysteme in der heutigen digitalen Welt schnell, sicher und zuverlässig miteinander zu vernetzen und zusammenarbeiten zu lassen. Aber wie funktioniert eigentlich eine API?
Wie funktioniert eine API in der Praxis?
Zunächst müssen bei einer API-Schnittstelle technische und praktische Aspekte definiert werden, um die Kommunikation zwischen den Systemen überhaupt zu ermöglichen. Beispielsweise wird vereinbart, dass alle Informationen über das HTTP-Protokoll im Internet übertragen werden und ein bestimmtes Format wie XML oder JSON verwendet wird. Es gibt technische Standard-API-Formate, wie die REST-API, bei denen solche allgemeinen Vereinbarungen bereits festgelegt sind. Dadurch braucht man beim Design einer API weniger Zeit zu investieren, es ist nur wichtig, die passende Wahl zu treffen. Später in diesem Text werden wir einige dieser technischen API-Formate wie REST, SOAP, RPC und GraphQL detaillierter erläutern.
Was jede API einzigartig macht, sind die Daten und Anweisungen, die Systeme über eine API austauschen können. Außerdem werden Vereinbarungen getroffen, was das empfangende System mit den übermittelten Daten machen soll. Eine API ermöglicht es also, einem anderen System aus der Ferne Anweisungen zu erteilen. Daher auch der Begriff Application Programming Interface – eine Schnittstelle, über die Anwendungen durch Anweisungen ferngesteuert programmiert werden können.
Am besten lässt sich eine API mit einem Kellner in einem Restaurant vergleichen. Sie bestellen eine Suppe beim Kellner. Der Kellner geht in die Küche und gibt die Bestellung an den Koch weiter. Sie müssen nicht selbst in die Küche gehen oder dem Koch erklären, wie man die Suppe zubereitet.
Wie funktioniert das bei der Verbindung zwischen einem Reservierungssystem und einer Reise-App? Zunächst kann vereinbart werden, dass eine REST-API verwendet wird. Über diese API können beispielsweise folgende Informationen ausgetauscht werden:
Die Reise-App sendet die Reisedaten (Reiseziel, Datum, Anzahl der Kinder/Erwachsenen) über die API an mehrere Reservierungssysteme.
Die Systeme suchen anhand der erhaltenen Daten nach passenden Flügen, prüfen die Verfügbarkeit und ermitteln die Preise. Diese Informationen werden zurückgesendet.
Die Reise-App präsentiert dem Kunden alle verfügbaren Flüge.
Wählt der Kunde einen Flug aus, sendet die Reise-App eine Buchungsanfrage an das entsprechende Reservierungssystem. Das System verarbeitet die Anfrage und bucht den Flug.
Das Reservierungssystem sendet eine Bestätigung zurück und liefert auch Zahlungsanweisungen. Und so weiter.
Mit dieser API ist klar definiert, wie die Reise-App und die Reservierungssysteme technisch zusammenarbeiten. Der Vorteil ist, dass bei neuen Verbindungsanfragen von anderen Reise-Apps die gleiche API verwendet werden kann. Alle Details sind bereits in der API festgelegt, sodass es nahezu Plug-and-Play ist.
Beispiele für APIs
Vergleichbar mit dem oben genannten Beispiel aus der Luftfahrt gibt es zahllose APIs in allen Branchen. Einige davon werden branchenweit genutzt, um Anwendungen zu verknüpfen. Andere APIs sind universeller und finden in deutlich breiteren Anwendungen Einsatz. Wenn Sie beispielsweise Google Maps auf einer Website oder in einer Anwendung verwenden möchten, können Sie dies über die definierte Google API tun. Im Folgenden geben wir einige Beispiele für APIs, die in verschiedenen Branchen verwendet werden.
API im Gesundheitswesen
Im Gesundheitswesen schreitet die Digitalisierung rasch voran. Gesundheitseinrichtungen verwenden zahlreiche Systeme, von Standard-Büroanwendungen bis hin zu speziellen medizinischen Systemen und Anwendungen. Diese Systeme, oft Standardsoftware, werden in verschiedenen Organisationen genutzt und müssen auf vielseitige Weise mit anderen Systemen verknüpft werden können. Ein Beispiel hierfür ist Nedap Ons, eine umfassende Softwarelösung zur Optimierung administrativer Prozesse in Gesundheitseinrichtungen. Sie bietet Funktionen für das Management von Mitarbeiter- und Klientendaten, Planung und Autorisierung. Um eine Verbindung mit anderen Systemen herzustellen, bietet Nedap eine REST API an, die den Zugang zu den Diensten und Daten der Plattform ermöglicht.
API für die öffentliche Verwaltung
Gemeinden sind komplexe Organisationen mit einer Vielzahl an verwendeten Systemen. Viele Aufgaben umfassen langfristige Vorgänge, wie die Beantragung von Genehmigungen, Subventionen oder die Verlängerung von Pässen. Diese Prozesse werden in sogenannten Vorgangssystemen verwaltet, die sämtliche relevanten Daten zu einer Angelegenheit speichern. Vorgangssysteme benötigen zahlreiche Schnittstellen, zum Beispiel zu einem Kundendienstzentrum (KCC), damit Bürgeranfragen schnell und effizient beantwortet werden können. Auch andere kommunale IT-Systeme greifen auf Informationen eines Vorgangssystems zu. Deshalb wurde beschlossen, dass Vorgangssysteme die APIs für vorgangsorientiertes Arbeiten nutzen sollen. Dadurch müssen Daten nicht mehr zwischen den Systemen kopiert werden, da sie direkt im Quellsystem abgerufen werden können. Diese API fördert die Digitalisierung und Effizienz der Gemeinden.
API für die Geschäftswelt
Im Bereich Human Resources (HR) nimmt die Abteilung eine immer zentralere Rolle im Unternehmen ein. Sie geht über rein administrative Aufgaben hinaus und konzentriert sich verstärkt auf die Gewinnung und Bindung von Talenten. Moderne HR-Systeme werden zunehmend als zentrale Quelle für andere Prozesse genutzt, von der Lohnbuchhaltung bis zur Erstellung von Benutzerkonten. Deshalb verfügen Systeme wie AFAS und Visma über APIs, die HR-Daten für andere Systeme zugänglich machen. Visma Raet, eine Lösung für öffentliche Organisationen, Gesundheits- und Bildungseinrichtungen, bietet beispielsweise die Visma.net HRM & Payroll API an, die eine Integration mit selbst entwickelten Systemen oder Drittanbieter-Anwendungen ermöglicht.
Der Unterschied zwischen APIs und Webservices
Manchmal werden die Begriffe API und Webservice synonym verwendet. Es ist daher hilfreich, den Begriff Webservice genauer zu betrachten. Ein Webservice ermöglicht es, Anwendungen über das Internet für externe Systeme zugänglich zu machen. Eine Webshop-Anwendung muss beispielsweise keine eigene Zahlungsabwicklung entwickeln. Sie kann über einen Webservice einfach mit einem Zahlungsanbieter verbunden werden, der die Zahlungen abwickelt.
Ein Webservice fungiert also als eine API zwischen dem Zahlungsanbieter und den angeschlossenen Webshops, ist jedoch eine spezielle Art von API. Ein solcher Webservice ist ausschließlich für die Kommunikation über das Internet konzipiert. Das Format ist durch die Web Service Definition Language (WSDL) definiert, und es werden stets spezifische Standards wie SOAP, HTTP und XML verwendet.
Ein Webservice ist somit eine von vielen Arten von APIs, die heute genutzt werden. Es gibt jedoch auch viele APIs, die anders funktionieren. Einige nutzen andere Netzwerke, Standards oder Datenformate. Tatsächlich existieren auch APIs, die ganz ohne Netzwerke arbeiten und dafür verwendet werden, Systeme direkt zu verbinden. Darüber hinaus gibt es APIs, die verschiedene Anwendungen innerhalb eines einzigen Systems miteinander verknüpfen. Ein Betriebssystem wie Windows enthält beispielsweise zahlreiche APIs, die die Zusammenarbeit von Anwendungen, Peripheriegeräten usw. auf einem Computer ermöglichen. Ein Webservice ist also eine API, aber nicht jede API ist ein Webservice.Verschillende soorten API’s en voordelen
Was ist eine REST (JSON, XML, HTML) API?
REST steht für Representational State Transfer. Die REST API – oder genauer gesagt die RESTful API – wurde im Jahr 2000 entwickelt und ist aufgrund ihrer Flexibilität sehr beliebt. Die Informationen können über verschiedene Protokolle übertragen werden, wobei – insbesondere in Webumgebungen – meist das HTTP-Protokoll verwendet wird, sodass keine zusätzliche API-Software benötigt wird, um sie zu verwenden. Standard-HTTP-Methoden wie GET, POST, PUT und DELETE können genutzt werden, und da kurze Nachrichten verwendet werden, sind REST APIs relativ schnell. Eine REST API ist zudem stateless; es wird keine Sitzungsinformation gespeichert, sodass jede Anfrage an ein System alle notwendigen Informationen enthalten muss.
REST APIs unterstützen verschiedene Datenformate. Nicht nur JSON (JavaScript Object Notation), das mit seiner relativ leichten, einfachen Struktur in Webumgebungen sehr beliebt ist. Auch das stärker strukturierte XML (eXtensible Markup Language) Format, das vor allem für komplexere Daten verwendet wird. Darüber hinaus ist HTML (HyperText Markup Language), die Auszeichnungssprache für Webseiten, eine Option. REST APIs eignen sich besonders für „leichtgewichtige“ APIs und werden bei zahlreichen Online-Diensten verwendet, von X bis Spotify.
Was ist eine SOAP (XML) API?
Das Simple Object Access Protocol (SOAP) ist ein echter Veteran unter den Protokollen; SOAP existiert mittlerweile seit 25 Jahren. SOAP-APIs werden häufig für Webservices verwendet und nutzen das HTTP-Protokoll. Außerdem gibt es auch noch Legacy-SOAP-Verbindungen, die Informationen über SMTP (Simple Mail Transfer Protocol) transportieren. SOAP verwendet XML. Wie oben bereits beschrieben, ist das ein stärker strukturiertes Informationsformat, was Nachrichten länger macht und den Datenaustausch verlangsamt. SOAP ist für einfache Webanwendungen zwar etwas „schwer“, aber sehr gut geeignet, um komplexe Datenaustauschprozesse in Unternehmensumgebungen zu unterstützen. Zudem bietet SOAP fortschrittlichere Sicherheitsmaßnahmen. Mit diesen Eigenschaften wird SOAP häufig in Zahlungsdiensten sowie in der Kommunikation zwischen Banken und anderen großen Geschäftsumgebungen eingesetzt.
Was ist eine RPC (TCP, UDP) API?
RPC steht für Remote Procedure Call. Dies ist ein schon länger bestehender Ansatz, und es lässt sich darüber streiten, ob es sich wirklich um eine API handelt. Wir verglichen zuvor eine API mit dem Kellner in einem Restaurant, einer Art „Man-in-the-Middle“. Setzt man diesen Vergleich fort, könnte man RPC besser mit einem Restaurantbesucher vergleichen, der direkt lautstark in die Küche ruft, dass er Suppe möchte. Bei RPC kann eine Anwendung nämlich direkt eine Funktion innerhalb des empfangenden Systems aufrufen. Das hat Vorteile – es ist direkt, schnell und leistungsstark – jedoch ist die Kommunikation weder standardmäßig abgesichert noch besonders flexibel. Möchte man das System dazu bringen, etwas anderes zu tun, muss man die Schnittstelle erneut anpassen. Die Kommunikation erfolgt über TCP (Transmission Control Protocol) oder UDP (Datagram Protocol).
Was ist eine GraphQL (HTTP) API?
GraphQL wurde von Facebook entwickelt und ist aufgrund der umfangreichen Filtermöglichkeiten interessant. Außerdem können Anfragen gleichzeitig an verschiedene Systeme gesendet werden. Tatsächlich kann man in einer Query schon exakt filtern, welche Informationen man sucht, und nur diese Daten werden anschließend zurückgesendet. Die Komplexität mehrerer verbundener Systeme wird verborgen, und man erhält die zusammenhängenden Ergebnisse der Query zurück.
Vergleichstabelle
API | REST API | SOAP API | RPC API | GraphQL API |
|---|---|---|---|---|
Allgemein | Basierend auf Standard-HTTP-Methoden (GET, POST, PUT etc.) | Nutzt XML, normalerweise über HTTP | Einfache Prozeduraufrufe durch direkte Funktionsaufrufe | Abfragesprache für verteilte Systeme |
Datenformate | JSON, XML oder HTML, andere Optionen möglich | XML | XML, JSON, andere Optionen möglich | Meist JSON, unterstützt aber auch andere Formate |
Protokolle | Normalerweise HTTP-Protokolle, andere Optionen möglich | Kann verschiedene Protokolle nutzen, wie HTTP, SMTP etc. | Meist TCP oder UDP | Verwendet HTTP, zugrundeliegendes Protokoll kann variieren |
Stateful oder stateless | Immer stateless | Stateless und stateful | Stateless und stateful | Normalerweise stateless, gelegentlich stateful |
Flexibilität | Mehr Flexibilität bei Endpoint-URLs und Datenformaten | Weniger flexibel, erfordert explizite Definition von Datenstrukturen und Aktionen | Weniger flexibel durch direkte Methodenaufrufe | Bietet hohe Flexibilität, da der Client die benötigten Daten spezifizieren kann |
Geschwindigkeit | Allgemein schneller durch weniger Overhead | Kann mehr Overhead haben und dadurch langsamer sein | Kann schnell sein durch direkte Aufrufe der Zielanwendung | Effizient, da nur benötigte Daten abgerufen werden |
Sicherheit | Unterstützt, mit Fokus auf korrekte Implementierung von Authentifizierung und Autorisierung | Kann komplexe Sicherheitsoptionen bieten (z. B. WS-Security) | Benötigt zusätzliche Sicherheitsmaßnahmen | Bietet Sicherheit auf Feldebene |
Vorteile der Nutzung einer API
Mit APIs können wir problemlos Funktionen aus verschiedenen Systemen kombinieren, um neue Anwendungen zu erstellen. Bestehende Anwendungen und Funktionen werden dabei so weit wie möglich wiederverwendet, sodass der Fokus auf neuen Entwicklungen liegen kann. Im Beispiel der Reise-App kann sich der Betreiber vollständig auf die Entwicklung der App konzentrieren, während die Flugdaten aus Reservierungssystemen vorrangig über bestehende Funktionalitäten und standardisierte API-Schnittstellen integriert werden. Auf diese Weise kann man sich auf wesentliche Neuerungen konzentrieren, während die Implementierung der Gesamtlösung überschaubar, sicher und flexibel bleibt. Im Folgenden wird dies weiter erläutert.
Gefühl der Kontrolle
Digitale Innovation steht und fällt mit der Möglichkeit, unterschiedliche Systeme einfach zusammenarbeiten zu lassen. Auf diese Weise können bestehende Funktionalitäten problemlos wiederverwendet oder Daten aus anderen Systemen einfach abgerufen werden. Gleichzeitig muss dies jedoch kontrolliert erfolgen. Wenn wir ad hoc Verbindungen zwischen verschiedenen Systemen herstellen und direkt auf die Software und Daten anderer zugreifen, landen wir schnell in einer „Spaghetti-Architektur“ – eine Architektur, bei der jede noch so kleine Änderung dazu führt, dass die Funktionalität, Zuverlässigkeit oder Sicherheit beeinträchtigt wird.
Eine gute Architektur mit gut entwickelten und dokumentierten APIs ermöglicht es, dass Systeme kontrolliert auf die Funktionalitäten und Daten anderer zugreifen können. Der Eigentümer des Systems behält stets die Kontrolle darüber, wie diese Elemente genutzt werden dürfen, und andere Systeme erhalten niemals direkten Zugriff auf den Quellcode. Auch Systemanpassungen sind kein Problem. Über bestehende APIs bleiben bestehende Funktionen und Daten weiterhin zugänglich, während neue Funktionalitäten über ein API-Update bei Bedarf ebenfalls verfügbar gemacht werden können. Das Gesamtsystem bleibt „unter Kontrolle“.
Sicherheit der API
Wichtig ist, dass moderne APIs ein integraler Bestandteil der Informationssicherheit sind. Bevor Remote- und Hybrid-Arbeit weit verbreitet war, wurden Unternehmensnetzwerke oft noch wie eine Burg geschützt. Dabei bildeten die Mauern und das Tor die Sicherheitsmaßnahmen, aber dahinter gab es wenig, um Eindringlinge aufzuhalten. Ähnlich konzentrierten sich IT-Manager vollständig auf den Zugangsschutz zu ihrem Unternehmensnetzwerk. Einmal innerhalb des Netzwerks, gab es kaum noch Kontrolle über das Nutzerverhalten, und auch die Verbindungen zwischen Systemen waren oft einfach komplett „offen“.
Da wir nun alle remote und in der Cloud arbeiten, ist dieser traditionelle Schutz nicht mehr tragfähig.
Zero-Trust-Prinzip
IT-Anwendungen können remote von Benutzern aufgerufen werden, und Systeme kommunizieren über das Internet auch mit Systemen außerhalb der eigenen Organisation. Deshalb müssen moderne IT-Netzwerke auf dem Zero-Trust-Prinzip basieren, bei dem nichts und niemand blindlings vertraut wird. Bei jeder Benutzersitzung – und auch beim Informationsaustausch zwischen Systemen – muss gefragt werden, wer Zugang anfordert, welche Rolle er hat und welche Zugriffsrechte das System besitzt. Moderne Web-APIs ermöglichen dies. Wie man eine API sicher einsetzt, wird im Folgenden erläutert.
Flexibilität
Organisationen müssen als Ganzes immer schneller auf gesellschaftliche Veränderungen, Markttrends und technologische Innovationen reagieren können. Auch die IT muss zunehmend agiler werden. Anwendungen müssen schnell gekoppelt oder deaktiviert werden können. Mit modernen APIs unterstützen wir dies. Das Verbinden von Systemen erfordert nur selten ein langfristiges Systemintegrationsprojekt; meist kann eine API schnell konfiguriert und aktiviert werden.
Ein Beispiel hierfür sind moderne HR-Systeme, die mittels APIs an die übrigen Unternehmenssysteme angebunden sind. Oft wird nach einigen Jahren ein neues HR-Paket ausgewählt. Wenn ein anderes Paket gewählt wird, kann eine solche Migration dank der verfügbaren APIs schnell durchgeführt werden. Nicht nur kann die neue Anwendung zügig über eine API angeschlossen werden, auch die Datenübertragung in das neue System kann effizient über APIs erfolgen.
Sichere Implementierung einer API
Moderne APIs müssen gemäß dem Zero-Trust-Prinzip arbeiten. Das bedeutet, dass man bei einer Schnittstelle zwischen zwei Systemen niemals blind davon ausgehen darf, dass sie vertrauenswürdig ist. Genau wie Benutzer müssen sich auch Anwendungen authentifizieren (um zu wissen, mit wem man es zu tun hat), wenn sie Zugriff auf eine andere Anwendung anfordern. Ebenso muss das verbundene System über die entsprechende Autorisierung verfügen (was darf es tun?), um Befehle an das andere System erteilen zu können. Es wird immer wichtiger, dass Menschen und Systeme nur auf Funktionen und Daten zugreifen können, die wirklich notwendig sind. Insbesondere da zunehmend personenbezogene Daten zwischen Systemen übertragen werden.
GDPR-Regeln
Die DSGVO stellt hierfür strenge Regeln auf. Systeme dürfen personenbezogene Daten nur für klar definierte und gerechtfertigte Zwecke verarbeiten. Dies wird Zweckbindung genannt. Eine gut gestaltete API ermöglicht es, die Datenauswahl so zu konfigurieren, dass nur jene Daten geteilt werden, die die empfangende Anwendung tatsächlich benötigt. Wenn Sie beispielsweise ein HR-System mit einem Schulungstool verbinden, benötigt das Schulungstool keine Abwesenheitsdaten. Diese Daten sollten daher für diese Anwendung gesperrt sein.
Tipp: Testen Sie Ihre API.
Für die Autorisierung wird häufig der OAuth 2.0-Standard verwendet. Da der Fokus oft auf der Authentifizierung und Autorisierung von menschlichen Nutzern liegt, ist es besonders wichtig, auch die Sicherheit von APIs zu testen.
Effiziente API-Integrationen für Identity and Access Management
Wie werden innerhalb einer Identity & Access Management (IAM) Plattform APIs genutzt und welche IAM-APIs gibt es? Das erklären wir am Beispiel unseres cloudbasierten HelloID-Systems. Als IAM-Plattform verfügen wir über Schnittstellen zu sogenannten Quell- und Zielsystemen.
Quellsysteme sind häufig HR-Systeme wie AFAS und Visma Raet. Diese versorgen die IAM-Plattform mit Informationen über neue Mitarbeiter, Aufgabenänderungen und Austritte. Auf Grundlage dieser Informationen erstellen wir neue Benutzerkonten, verwalten Zugriffsrechte und deaktivieren letztendlich auch wieder Konten.
Zielsysteme sind die Systeme, an die wir diese Informationen anschließend weiterleiten. Wenn in HelloID ein Benutzerkonto registriert wurde und die zugehörigen Zugriffsrechte definiert wurden, erstellen wir beispielsweise Benutzerkonten in der Active Directory oder in Entra ID. Auch an Geschäftsanwendungen wie Nedap Ons – ein häufig genutztes System im Gesundheitswesen – und an Servicemanagementsysteme wie TOPdesk senden wir Kontodaten und Einstellungen.
Übrigens sind viele Quellsysteme wie AFAS gleichzeitig auch Zielsysteme. HelloID erstellt für neue Mitarbeiter ein Self-Service-Konto im HR-System, damit diese ihre persönlichen Daten verwalten und Gehaltsabrechnungen einsehen können.
200 Software-Schnittstellenstellen
IAM fungiert als zentraler Knotenpunkt zwischen allen Systemen. Um Systeme anzuschließen, bieten wir inzwischen über 200 Connectoren für bestehende Systeme an. Ein entscheidender Aspekt dieser Connectoren ist ihre Fähigkeit, sich mit einer Vielzahl von APIs zu integrieren, die jeweils unterschiedliche Merkmale und Formate aufweisen. Wie zuvor erläutert, variiert die Art dieser APIs erheblich – einige Systeme verwenden REST, andere SOAP oder GraphQL. Darüber hinaus unterscheiden sich die Art der Datenaustauschverfahren und die Anforderungen für Datenabfragen je nach API deutlich. Beispielsweise kann ein HR-System alle Mitarbeiterdaten direkt bereitstellen, während ein anderes System erfordert, zunächst eine Liste aller Mitarbeiter abzufragen, gefolgt von individuellen Datenabfragen (API-Calls) pro Mitarbeiter.
Die Hauptfunktion eines Connectors in diesem komplexen Umfeld besteht darin, diese unterschiedlichen Datenströme zu standardisieren. Unabhängig von der Vielfalt der APIs und der Formate, in denen sie Daten liefern, transformiert der Connector diese Daten in ein einheitliches Format. Dadurch bleibt der Datenaustausch zwischen den Systemen konsistent und effizient. Neben der Datenumwandlung können die Connectoren jedoch auch zusätzliche Logik und Kontrollmechanismen enthalten, die zu einer reibungslosen und zuverlässigen Integration beitragen. Mit den Connectoren ist HelloID in der Lage, Personen- und Vertragsdaten zu erfassen sowie Konten und Zugriffsrechte bereitzustellen. Unser Ansatz mit HelloID gewährleistet maximale Flexibilität und macht Anpassungen an den angeschlossenen Systemen in der Regel überflüssig. Somit bildet der Connector die Brücke zwischen der Vielfalt der APIs und den standardisierten Anforderungen unseres IAM-Systems.
Umgang mit API-Änderungen
Ändert ein Anbieter eines angeschlossenen Systems etwas an seiner API, passen wir den Connector entsprechend an. Dies kann auch erforderlich sein, wenn eine System-API neue Funktionen erhält. Bei einigen Zielsystemen kann HelloID aufgrund von API-Beschränkungen derzeit lediglich Basisaccounts erstellen oder löschen. Spezifische Zugriffsrechte müssen dann direkt im System selbst verwaltet werden, z. B. bei einem Gesundheitssystem, in dem festgelegt wird, wer Zugriff auf welche Patientendaten erhält. Sobald eine solche API jedoch durch den Anbieter erweitert wird, können wir unseren Connector entsprechend anpassen, sodass künftig auch diese detaillierten Einstellungen über HelloID verwaltet werden können.
Sehen Sie sich alle unterstützten Quell- und Zielsysteme an.
Alle Verknüpfungen