Skip to Content
DKSR Glossar
DKSR Glossar

API

API steht kurz für Application Programming Interface. Es handelt sich dabei um Schnittstellen zu und zwischen Software-Anwendungen.

Vor allem im Zuge von Web Services und Internet-der-Dinge (IoT) haben APIs an Bedeutung gewonnen. Sie ermöglichen es, Informationen (Daten) von Datenanbieter*in A zu Datenempfänger*in B zu senden bzw. zu empfangen. Dabei sind Anbieter*in A und Empfänger*in B nicht unbedingt Privatpersonen, sondern i.d.R. komplexe IT-Systeme oder Plattformen. Durch APIs ergeben sich völlig neue Möglichkeiten, Anwendungen zu entwickeln. Um APIs zu verwalten, benötigt es eine Applikation, die die gesendeten oder empfangenen Informationen aufbereitet und zugänglich macht bzw. zusammen mit weiteren Informationen aus anderen APIs verarbeitet.

Eine einfach API
Eine einfache API. Quelle: Experian

Umgangssprachlich könnte man eine API als Mittelsmenschen bezeichnen, der dabei hilft, Informationen zwischen den beiden Akteur*innen auszutauschen. Da es meist mit einem reinen Austausch nicht getan ist, benötigt der Mittelsmensch zusätzlich eine “Übersetzerfunktion” - also eine Softwarekomponente, die die gesendeten Informationen in ein Format umwandelt, das der Empfänger versteht. Dieser “Übersetzer” ist im Kontext von DKSR ein Konnektor.

Für technisch Interessierte gibt es in diesem Kontext noch weitere wissenswerte Begriffe.

Push- & Pull-Befehle

Oft hört man die Begriffe “Push API” und “Pull API”. Diese beziehen sich darauf, wann bzw. von wem der Befehl Daten zu senden ausgelöst wird.

Bei einer Push API werden neue Informationen automatisiert von Datensendenden zu Datenempfangenden geschickt. Ein einfaches Beispiel sind hier unsere Messengerdienste: Immer, wenn eine kleine rote Zahl bei Whatsapp erscheint wurde die neue Nachricht automatisiert zur*m Empfangenden gepusht.

Bei einer Pull API wird der Datentransfer vom*von dem*r Empfangenden initiiert. Der*die Empfangende fragt proaktiv bei dem*r Sender*in nach, ob es neue Informationen gibt. Beispielsweise bei E-Mail-Programmen gibt es oft die Möglichkeit, manuell den “Senden/Empfangen”-Button zu klicken. In diesem Moment initiiert der*die Empfangende durch Klick auf den Button eine Abfrage bei der API, ob es eine neue Mail zu lesen gibt.

Push API
Push - die neue Nachricht wird zu*r Empfänger*in “gedrückt”

 

Pull API
Pull - der*die Empfänger*in zieht aktiv eine neue Nachricht heran

 

 

 

 

 

 

 

Es gibt weitere Möglichkeiten wie “Polling” oder “Webhook”: Dies sind aber abgewandelte Formen der zwei Hauptarten “Push” und “Pull”.

 

Unterschiedliche API-Architekturen

  • SOAP (Simple Object Access Protocol):

Es handelt sich um ein Protokoll, das XML als Format für die Datenübertragung verwendet. Die Hauptfunktion des Protokolls besteht darin, die Struktur von Nachrichten und die Kommunikationsmethoden zu definieren. Es verwendet auch WSDL (Web Services Definition Language) in einem maschinenlesbaren Dokument, um eine Definition seiner Schnittstelle zu veröffentlichen.

  • XML-RPC:

Hierbei handelt es sich um ein Protokoll, das ein spezielles XML-Format zur Datenübertragung verwendet. XML-RPC ist älter als SOAP; es benötigt ein Minimum an Bandbreite und ist deutlich einfacher zu verwenden.

  • JSON-RPC:

Dieses Protokoll ist ähnlich wie XML-RPC, verwendet aber statt des XML-Formats JSON für die Datenübertragung. Bei JSON handelt es sich um ein von Programmiersprachen unabhängiges Format, um Daten zwischen Systemen auszutauschen.

  • REST (Representational State Transfer):

Bei REST handelt es sich nicht um ein Protokoll wie bei anderen Webdiensten, sondern um eine Reihe von Architekturprinzipien. Der REST-Dienst muss bestimmte Merkmale aufweisen; darunter einfache Schnittstellen, über die die Ressourcen innerhalb der Anfrage leicht identifiziert werden können. So muss auch die Manipulation von Ressourcen über die Schnittstelle einfach nachvollziehbar sein.

Back to top