Programmierschnittstelle
Eine Anwendungsprogrammierschnittstelle (API) ist eine Möglichkeit für zwei oder mehr Computerprogramme, miteinander zu kommunizieren. Sie ist eine Art Softwareschnittstelle, die einen Dienst für andere Software anbietet. Ein Dokument oder ein Standard, in dem beschrieben wird, wie eine solche Verbindung oder Schnittstelle aufgebaut oder verwendet werden kann, wird als API-Spezifikation bezeichnet. Ein Computersystem, das diese Norm erfüllt, implementiert oder stellt eine API zur Verfügung. Der Begriff API kann sich entweder auf die Spezifikation oder auf die Implementierung beziehen. ⓘ
Im Gegensatz zu einer Benutzerschnittstelle, die einen Computer mit einer Person verbindet, verbindet eine Anwendungsprogrammierschnittstelle Computer oder Softwareteile miteinander. Sie ist nicht dafür gedacht, direkt von einer Person (dem Endbenutzer) verwendet zu werden, sondern nur von einem Computerprogrammierer, der sie in die Software einbaut. Eine API besteht oft aus verschiedenen Teilen, die dem Programmierer als Werkzeuge oder Dienste zur Verfügung stehen. Ein Programm oder ein Programmierer, der einen dieser Teile verwendet, ruft diesen Teil der API auf. Die Aufrufe, aus denen die API besteht, werden auch als Unterroutinen, Methoden, Anfragen oder Endpunkte bezeichnet. Eine API-Spezifikation definiert diese Aufrufe, d. h. sie erklärt, wie sie zu verwenden oder zu implementieren sind. ⓘ
Ein Zweck von APIs ist es, die internen Details der Funktionsweise eines Systems zu verbergen, indem nur die Teile offengelegt werden, die für den Programmierer nützlich sind, und diese konsistent zu halten, auch wenn sich die internen Details später ändern. Eine API kann für ein bestimmtes Systempaar maßgeschneidert sein, oder sie kann ein gemeinsamer Standard sein, der die Interoperabilität zwischen vielen Systemen ermöglicht. ⓘ
Der Begriff API wird häufig im Zusammenhang mit Web-APIs verwendet, die die Kommunikation zwischen Computern ermöglichen, die über das Internet miteinander verbunden sind. Es gibt auch APIs für Programmiersprachen, Softwarebibliotheken, Computerbetriebssysteme und Computerhardware. APIs haben ihren Ursprung in den 1940er Jahren, obwohl der Begriff erst in den 1960er und 1970er Jahren aufkam. Jüngste Entwicklungen bei der Nutzung von APIs haben dazu geführt, dass Microservices immer beliebter werden, bei denen es sich letztlich um lose gekoppelte Dienste handelt, auf die über öffentliche APIs zugegriffen wird. ⓘ
Eine Programmierschnittstelle (auch Anwendungsschnittstelle, genauer Schnittstelle zur Programmierung von Anwendungen), häufig nur kurz API genannt (von englisch application programming interface, wörtlich ‚Anwendungsprogrammierschnittstelle‘), ist ein Programmteil, der von einem Softwaresystem anderen Programmen zur Anbindung an das System zur Verfügung gestellt wird. Im Gegensatz zu einer Binärschnittstelle (ABI) definiert eine Programmierschnittstelle nur die Programmanbindung auf Quelltext-Ebene. Zur Bereitstellung solch einer Schnittstelle gehört meist die detaillierte Dokumentation der Schnittstellen-Funktionen mit ihren Parametern auf Papier oder als elektronisches Dokument. ⓘ
Neben dem Zugriff auf Datenbanken oder Hardware wie Festplatte oder Grafikkarte kann eine Programmierschnittstelle auch das Erstellen von Komponenten der grafischen Benutzeroberfläche ermöglichen oder vereinfachen. Zum Beispiel ermöglicht die Programmierschnittstelle Windows Application Programming Interface des Betriebssystems Windows, dass externe Firmen überhaupt erst Software für dieses Betriebssystem entwickeln können. ⓘ
Heutzutage stellen auch viele Online-Dienste Programmierschnittstellen zur Verfügung; diese heißen dann Webservice. Im weiteren Sinne wird die Schnittstelle jeder Bibliothek (englisch library) als Programmierschnittstelle bezeichnet. Zu unterscheiden ist diese Art funktionaler Programmierschnittstellen von den vielen anderen Schnittstellen, die in der Programmierung angewendet werden – zum Beispiel die Parameter, die beim Aufruf von Unterprogrammen vereinbart und übergeben werden. ⓘ
Zweck
Bei der Erstellung von Anwendungen vereinfacht eine API die Programmierung, indem sie die zugrunde liegende Implementierung abstrahiert und nur die Objekte oder Aktionen offenlegt, die der Entwickler benötigt. Während eine grafische Schnittstelle für einen E-Mail-Client dem Benutzer eine Schaltfläche zur Verfügung stellt, die alle Schritte zum Abrufen und Markieren neuer E-Mails ausführt, kann eine API für die Dateieingabe/-ausgabe dem Entwickler eine Funktion zur Verfügung stellen, die eine Datei von einem Speicherort zu einem anderen kopiert, ohne dass der Entwickler die Dateisystemoperationen im Hintergrund verstehen muss. ⓘ
Geschichte des Begriffs
Ursprünglich beschrieb der Begriff API nur eine Schnittstelle für Programme, die für den Endbenutzer bestimmt waren, die so genannten Anwendungsprogramme. Dieser Ursprung spiegelt sich noch immer in der Bezeichnung "Anwendungsprogrammierschnittstelle" wider. Heute ist der Begriff weiter gefasst und schließt auch Dienstprogramme und sogar Hardwareschnittstellen mit ein. ⓘ
1940er und 1950er Jahre
Die Idee der API ist viel älter als der Begriff selbst. Die britischen Informatiker Maurice Wilkes und David Wheeler arbeiteten in den 1940er Jahren an einer modularen Softwarebibliothek für EDSAC, einen frühen Computer. Die Unterprogramme in dieser Bibliothek wurden auf Lochstreifen in einem Aktenschrank gespeichert. Dieser Schrank enthielt auch einen "Bibliothekskatalog", wie Wilkes und Wheeler ihn nannten, mit Notizen zu jedem Unterprogramm und dazu, wie man es in ein Programm einbauen konnte. Heute würde man einen solchen Katalog als API (oder API-Spezifikation oder API-Dokumentation) bezeichnen, da er dem Programmierer vorschreibt, wie er jedes Unterprogramm, das er benötigt, verwenden (oder "aufrufen") kann. ⓘ
Das Buch The Preparation of Programs for an Electronic Digital Computer von Wilkes und Wheeler aus dem Jahr 1951 enthält die erste veröffentlichte API-Spezifikation. Joshua Bloch ist der Ansicht, dass Wilkes und Wheeler die API "latent erfunden" haben, da es sich eher um ein Konzept handelt, das entdeckt als erfunden wurde. ⓘ
1960er und 1970er Jahre
Der Begriff "Application Program Interface" (ohne die Endung -ing) wird erstmals in einem Papier mit dem Titel Data structures and techniques for remote computer graphics erwähnt, das 1968 auf einer AFIPS-Konferenz vorgestellt wurde. Die Autoren dieses Papiers verwenden den Begriff, um die Interaktion einer Anwendung - in diesem Fall eines Grafikprogramms - mit dem Rest des Computersystems zu beschreiben. Eine konsistente Anwendungsschnittstelle (bestehend aus Fortran-Subroutinenaufrufen) sollte den Programmierer von den Eigenheiten des Grafikanzeigegeräts befreien und Hardwareunabhängigkeit bieten, wenn der Computer oder das Anzeigegerät ausgetauscht wurden. ⓘ
Der Begriff wurde 1974 von C. J. Date in einem Aufsatz mit dem Titel The Relational and Network Approaches: Comparison of the Application Programming Interface. Eine API wurde Teil des ANSI/SPARC-Rahmens für Datenbankmanagementsysteme. In diesem Rahmen wurde die Anwendungsprogrammierschnittstelle getrennt von anderen Schnittstellen, wie z. B. der Abfrageschnittstelle, behandelt. In den 1970er Jahren stellten Datenbankspezialisten fest, dass diese verschiedenen Schnittstellen kombiniert werden konnten; eine ausreichend umfangreiche Anwendungsschnittstelle konnte auch die anderen Schnittstellen unterstützen. ⓘ
Diese Feststellung führte zu APIs, die alle Arten der Programmierung unterstützten, nicht nur die Anwendungsprogrammierung. ⓘ
1990s
1990 definierte der Technologe Carl Malamud die API einfach als "eine Reihe von Diensten, die einem Programmierer zur Ausführung bestimmter Aufgaben zur Verfügung stehen". ⓘ
Mit dem Aufkommen von Remote Procedure Calls und Web-APIs wurde das Konzept der API erneut erweitert. Mit der Verbreitung von Computernetzwerken in den 1970er und 1980er Jahren wollten Programmierer Bibliotheken aufrufen, die sich nicht nur auf ihren lokalen Computern, sondern auch auf Computern an anderen Orten befanden. Diese Remote Procedure Calls wurden insbesondere von der Sprache Java gut unterstützt. In den 1990er Jahren, mit der Verbreitung des Internets, konkurrierten Standards wie CORBA, COM und DCOM darum, die gängigste Methode zur Bereitstellung von API-Diensten zu werden. ⓘ
2000s
In seiner Dissertation Architectural Styles and the Design of Network-based Software Architectures (Architekturstile und Entwurf netzwerkbasierter Softwarearchitekturen), die Roy Fielding im Jahr 2000 an der UC Irvine schrieb, stellte er Representational State Transfer (REST) vor und beschrieb die Idee einer "netzwerkbasierten Anwendungsprogrammierschnittstelle", die Fielding den traditionellen "bibliotheksbasierten" APIs gegenüberstellte. XML- und JSON-Web-APIs wurden ab dem Jahr 2000 auf breiter Basis kommerziell eingesetzt und werden auch 2022 noch verwendet. Die Web-API ist heute die häufigste Bedeutung des Begriffs API. ⓘ
Das von Tim Berners-Lee 2001 vorgeschlagene Semantic Web umfasst "semantische APIs", die die API als offene, verteilte Datenschnittstelle und nicht als Schnittstelle für Softwareverhalten neu definieren. Proprietäre Schnittstellen und Agenten wurden weiter verbreitet als offene, aber die Idee der API als Datenschnittstelle setzte sich durch. Da Web-APIs in großem Umfang für den Online-Austausch von Daten aller Art verwendet werden, ist API zu einem weit gefassten Begriff geworden, der einen Großteil der Kommunikation im Internet beschreibt. Bei dieser Verwendung überschneidet sich die Bedeutung des Begriffs API mit dem Begriff Kommunikationsprotokoll. ⓘ
Verwendung
Bibliotheken und Frameworks
Die Schnittstelle zu einer Softwarebibliothek ist eine Art von API. Die API beschreibt und schreibt das "erwartete Verhalten" (eine Spezifikation) vor, während die Bibliothek eine "tatsächliche Implementierung" dieses Regelwerks ist. ⓘ
Eine einzelne API kann mehrere Implementierungen haben (oder keine, da sie abstrakt ist), und zwar in Form verschiedener Bibliotheken, die dieselbe Programmierschnittstelle nutzen. ⓘ
Die Trennung der API von ihrer Implementierung kann es Programmen, die in einer Sprache geschrieben wurden, ermöglichen, eine in einer anderen Sprache geschriebene Bibliothek zu verwenden. Da Scala und Java zu kompatiblem Bytecode kompiliert werden, können Scala-Entwickler zum Beispiel jede Java-API nutzen. ⓘ
Die Verwendung von APIs kann je nach Art der Programmiersprache variieren. Eine API für eine prozedurale Sprache wie Lua könnte in erster Linie aus grundlegenden Routinen bestehen, um Code auszuführen, Daten zu manipulieren oder Fehler zu behandeln, während eine API für eine objektorientierte Sprache wie Java eine Spezifikation von Klassen und ihren Klassenmethoden bieten würde. Das Hyrum'sche Gesetz besagt: "Bei einer ausreichenden Anzahl von Nutzern einer API spielt es keine Rolle, was Sie im Vertrag versprechen: Alle beobachtbaren Verhaltensweisen Ihres Systems werden von jemandem in Anspruch genommen." Inzwischen zeigen mehrere Studien, dass die meisten Anwendungen, die eine API nutzen, dazu neigen, einen kleinen Teil der API zu verwenden. Die API-Nutzung hängt von der Anzahl der Benutzer und der Popularität der API ab. ⓘ
Sprachbindungen sind ebenfalls APIs. Durch die Abbildung der Merkmale und Fähigkeiten einer Sprache auf eine Schnittstelle, die in einer anderen Sprache implementiert ist, ermöglicht eine Sprachbindung die Verwendung einer Bibliothek oder eines Dienstes, die in einer Sprache geschrieben wurden, bei der Entwicklung in einer anderen Sprache. ⓘ
Werkzeuge wie SWIG und F2PY, ein Schnittstellengenerator von Fortran zu Python, erleichtern die Erstellung solcher Schnittstellen. ⓘ
Eine API kann auch mit einem Software-Framework in Verbindung gebracht werden: Ein Framework kann auf mehreren Bibliotheken basieren, die mehrere APIs implementieren, aber anders als bei der normalen Verwendung einer API wird der Zugriff auf das in das Framework eingebaute Verhalten durch die Erweiterung seines Inhalts mit neuen Klassen vermittelt, die in das Framework selbst eingesteckt werden. ⓘ
Darüber hinaus kann der gesamte Kontrollfluss des Programms der Kontrolle des Aufrufers entzogen und durch Umkehrung der Kontrolle oder einen ähnlichen Mechanismus in die Hände des Frameworks gelegt werden. ⓘ
Betriebssysteme
Eine API kann die Schnittstelle zwischen einer Anwendung und dem Betriebssystem spezifizieren. POSIX beispielsweise spezifiziert eine Reihe gemeinsamer APIs, die es ermöglichen sollen, dass eine Anwendung, die für ein POSIX-konformes Betriebssystem geschrieben wurde, für ein anderes POSIX-konformes Betriebssystem kompiliert werden kann. ⓘ
Linux und Berkeley Software Distribution sind Beispiele für Betriebssysteme, die die POSIX-APIs implementieren. ⓘ
Microsoft hat sich stark für eine abwärtskompatible API eingesetzt, insbesondere in seiner Windows-API-Bibliothek (Win32), so dass ältere Anwendungen unter neueren Windows-Versionen laufen können, wenn eine ausführungsspezifische Einstellung namens "Kompatibilitätsmodus" verwendet wird. ⓘ
Eine API unterscheidet sich von einer Application Binary Interface (ABI) dadurch, dass eine API quellcodebasiert ist, während eine ABI binärbasiert ist. So bietet POSIX beispielsweise APIs, während die Linux Standard Base eine ABI bereitstellt. ⓘ
Die Entwicklungsumgebung Xcode, mit der auf die API des Smartphone-Betriebssystems Apple iOS zugegriffen werden kann, steht zwar als kostenloser Download bereit, aber nur für Mac-Computer von Apple. Zudem müssen Entwickler ein Geheimhaltungsabkommen unterzeichnen und einen Mitgliedsbeitrag entrichten, was als Hemmnis bewertet wird – zumal Apple auf dem Markt für Smartphones bzw. Mobile Apps durch den großen Erfolg des Android-Betriebssystems mit starker Konkurrenz konfrontiert ist. ⓘ
Für die Betriebssystem-Familie Unix existiert der von der IEEE festgelegte POSIX-Standard. Die Preise für die Dokumentation dieser API sind sehr hoch, und die Veröffentlichung ist durch Urheberrecht untersagt. In neuerer Zeit ist deshalb eine Tendenz zur Single UNIX Specification der Open Group zu verzeichnen. Diese Standards sind offen, im Internet frei verfügbar und alle können Vorschläge dazu einreichen. ⓘ
Entfernte APIs
Remote-APIs ermöglichen es Entwicklern, Remote-Ressourcen über Protokolle zu manipulieren. Dabei handelt es sich um spezifische Kommunikationsstandards, die es ermöglichen, dass verschiedene Technologien unabhängig von Sprache oder Plattform zusammenarbeiten. Die Java Database Connectivity API ermöglicht es Entwicklern beispielsweise, viele verschiedene Datenbanktypen mit demselben Funktionssatz abzufragen, während die Java Remote Method Invocation API das Java Remote Method Protocol verwendet, um den Aufruf von Funktionen zu ermöglichen, die aus der Ferne arbeiten, aber für den Entwickler lokal erscheinen. ⓘ
Daher sind Remote-APIs nützlich, um die Objektabstraktion in der objektorientierten Programmierung aufrechtzuerhalten; ein Methodenaufruf, der lokal auf einem Proxy-Objekt ausgeführt wird, ruft die entsprechende Methode auf dem Remote-Objekt unter Verwendung des Remoting-Protokolls auf und erhält das Ergebnis, das lokal als Rückgabewert verwendet werden kann. ⓘ
Eine Änderung des Proxy-Objekts führt auch zu einer entsprechenden Änderung des entfernten Objekts. ⓘ
Web-APIs
Web-APIs sind ein Dienst, auf den von Client-Geräten (Mobiltelefonen, Laptops usw.) über das Hypertext Transfer Protocol (HTTP) auf einen Webserver zugegriffen wird. Client-Geräte senden eine Anfrage in Form einer HTTP-Anforderung und erhalten eine Antwortnachricht, in der Regel im Format JavaScript Object Notation (JSON) oder Extensible Markup Language (XML). Entwickler verwenden Web-APIs in der Regel, um einen Server nach einem bestimmten Datensatz abzufragen, der sich auf diesem Server befindet. ⓘ
Ein Beispiel wäre eine API für ein Versandunternehmen, die einer auf eCommerce ausgerichteten Website hinzugefügt werden kann, um die Bestellung von Versanddiensten zu erleichtern und automatisch aktuelle Versandtarife einzubeziehen, ohne dass der Website-Entwickler die Tariftabelle des Versandunternehmens in eine Webdatenbank eingeben muss. Während "Web-API" in der Vergangenheit praktisch gleichbedeutend mit Webservice war, geht der jüngste Trend (das so genannte Web 2.0) weg von Webservices auf der Grundlage des Simple Object Access Protocol (SOAP) und der serviceorientierten Architektur (SOA) hin zu Webressourcen im Stil des Representational State Transfer (REST) und der ressourcenorientierten Architektur (ROA). Ein Teil dieses Trends steht im Zusammenhang mit der Semantic Web-Bewegung in Richtung Resource Description Framework (RDF), einem Konzept zur Förderung webbasierter Ontologietechniken. Web-APIs ermöglichen die Kombination mehrerer APIs zu neuen Anwendungen, die als Mashups bekannt sind. ⓘ
Im Bereich der sozialen Medien haben Web-APIs es Webgemeinschaften ermöglicht, Inhalte und Daten zwischen Gemeinschaften und Anwendungen auszutauschen. Auf diese Weise können Inhalte, die an einem Ort dynamisch erstellt werden, an mehreren Stellen im Web veröffentlicht und aktualisiert werden. Die REST-API von Twitter ermöglicht Entwicklern beispielsweise den Zugriff auf Twitter-Kerndaten, und die Such-API bietet Entwicklern Methoden zur Interaktion mit Twitter-Such- und Trenddaten. ⓘ
Entwurf
Das Design einer API hat einen erheblichen Einfluss auf ihre Nutzung. Zunächst einmal ist das Design von Programmierschnittstellen ein wichtiger Teil der Softwarearchitektur, also der Organisation einer komplexen Software. Das Prinzip des "Information Hiding" beschreibt die Rolle von Programmierschnittstellen darin, dass sie die modulare Programmierung ermöglichen, indem sie die Implementierungsdetails der Module verbergen, so dass die Benutzer der Module die Komplexität innerhalb der Module nicht verstehen müssen. Neben dem vorgenannten Grundsatz können auch andere Kriterien zur Messung der Benutzerfreundlichkeit einer API herangezogen werden, z. B. funktionale Effizienz, allgemeine Korrektheit und Erlernbarkeit für Neulinge. Eine einfache und weit verbreitete Methode für den Entwurf von APIs ist die Befolgung der heuristischen Bewertungsrichtlinien von Nielsen. Das Factory-Methodenmuster ist ebenfalls typisch für den Entwurf von APIs, da sie wiederverwendbar sind. Beim Entwurf einer API wird also versucht, nur die Werkzeuge bereitzustellen, die ein Benutzer erwarten würde. ⓘ
Sicherheit
Die API-Sicherheit ist bei der Entwicklung einer öffentlich zugänglichen API sehr wichtig. Zu den üblichen Bedrohungen gehören SQL-Injection, Denial-of-Service-Angriffe (DoS), fehlerhafte Authentifizierung und die Offenlegung sensibler Daten. Ohne angemessene Sicherheitspraktiken können böswillige Akteure Zugang zu Informationen erhalten, die sie nicht haben sollten, oder sogar die Berechtigung erlangen, Änderungen an Ihrem Server vorzunehmen. Zu den gängigen Sicherheitspraktiken gehören eine ordnungsgemäße Verbindungssicherheit mit HTTPS, Inhaltssicherheit zur Eindämmung von Dateninjektionsangriffen und die Anforderung eines API-Schlüssels zur Nutzung Ihres Dienstes. Viele öffentlich zugängliche API-Dienste verlangen die Verwendung eines zugewiesenen API-Schlüssels und verweigern die Bereitstellung von Daten, wenn der Schlüssel nicht mit der Anfrage gesendet wird. ⓘ
Freigabe-Richtlinien
APIs sind eine der gängigsten Methoden zur Integration von Technologieunternehmen. Diejenigen, die APIs anbieten und nutzen, werden als Mitglieder eines geschäftlichen Ökosystems betrachtet. ⓘ
Die wichtigsten Richtlinien für die Freigabe einer API sind:
- Privat: Die API ist nur für den unternehmensinternen Gebrauch bestimmt.
- Partner: Nur bestimmte Geschäftspartner können die API nutzen. Zum Beispiel erlauben Mietwagenfirmen wie Uber und Lyft zugelassenen Drittentwicklern, direkt aus ihren Apps heraus Fahrten zu bestellen. Auf diese Weise können die Unternehmen eine Qualitätskontrolle ausüben, indem sie festlegen, welche Apps Zugang zur API haben, und sie erhalten eine zusätzliche Einnahmequelle.
- Öffentlich: Die API kann von der Öffentlichkeit genutzt werden. So macht Microsoft beispielsweise die Windows-API öffentlich, und Apple veröffentlicht seine Cocoa-API, damit Software für seine Plattformen geschrieben werden kann. Nicht alle öffentlichen APIs sind generell für jedermann zugänglich. Internetdienstleister wie Cloudflare oder Voxility verwenden beispielsweise RESTful-APIs, um Kunden und Wiederverkäufern den Zugriff auf ihre Infrastrukturinformationen, DDoS-Statistiken, Netzwerkleistung oder Dashboard-Kontrollen zu ermöglichen. Der Zugang zu solchen APIs wird entweder durch "API-Tokens" oder durch Validierung des Kundenstatus gewährt. ⓘ
Auswirkungen öffentlicher APIs
Ein wichtiger Faktor, wenn eine API öffentlich wird, ist ihre "Schnittstellenstabilität". Änderungen an der API - z. B. das Hinzufügen neuer Parameter zu einem Funktionsaufruf - könnten die Kompatibilität mit den Clients, die auf diese API angewiesen sind, beeinträchtigen. ⓘ
Wenn Teile einer öffentlich vorgestellten API Änderungen unterliegen und daher nicht stabil sind, sollten diese Teile einer bestimmten API ausdrücklich als "instabil" dokumentiert werden. In der Google Guava-Bibliothek sind beispielsweise die Teile, die als instabil gelten und sich möglicherweise bald ändern, mit der Java-Annotation @Beta gekennzeichnet. ⓘ
Eine öffentliche API kann manchmal Teile von sich selbst als veraltet oder zurückgezogen deklarieren. Dies bedeutet in der Regel, dass ein Teil der API als ein Kandidat für die Entfernung oder für eine abwärtskompatible Änderung betrachtet werden sollte. Daher ermöglichen diese Änderungen den Entwicklern den Übergang von Teilen der API, die entfernt oder in Zukunft nicht mehr unterstützt werden. ⓘ
Client-Code kann innovative oder opportunistische Verwendungen enthalten, die von den API-Designern nicht beabsichtigt waren. Mit anderen Worten: Wenn ein Element Teil der öffentlichen API wird, kann es bei einer Bibliothek mit einer großen Benutzerbasis auf unterschiedliche Weise verwendet werden. Am 19. Februar 2020 veröffentlichte Akamai seinen jährlichen "State of the Internet"-Bericht, der den wachsenden Trend aufzeigt, dass Cyberkriminelle öffentliche API-Plattformen bei Finanzdienstleistungen weltweit ins Visier nehmen. Von Dezember 2017 bis November 2019 verzeichnete Akamai 85,42 Milliarden Angriffe auf Zugangsdaten. Etwa 20 % davon, also 16,55 Milliarden, richteten sich gegen Hostnamen, die als API-Endpunkte definiert sind. Davon zielten 473,5 Millionen auf Organisationen im Finanzdienstleistungssektor ab. ⓘ
Dokumentation
Die API-Dokumentation beschreibt die Dienste, die eine API anbietet, und wie diese Dienste zu nutzen sind, und soll alles abdecken, was ein Kunde für praktische Zwecke wissen muss. ⓘ
Die Dokumentation ist entscheidend für die Entwicklung und Wartung von Anwendungen, die die API nutzen. API-Dokumentation findet sich traditionell in Dokumentationsdateien, kann aber auch in sozialen Medien wie Blogs, Foren und Q&A-Websites zu finden sein. ⓘ
Traditionelle Dokumentationsdateien werden häufig über ein Dokumentationssystem wie Javadoc oder Pydoc präsentiert, das ein einheitliches Erscheinungsbild und eine einheitliche Struktur aufweist. Die Arten von Inhalten, die in der Dokumentation enthalten sind, unterscheiden sich jedoch von API zu API. ⓘ
Im Interesse der Übersichtlichkeit kann die API-Dokumentation eine Beschreibung der Klassen und Methoden in der API sowie "typische Nutzungsszenarien, Codeschnipsel, Entwurfsüberlegungen, Leistungsdiskussionen und Verträge" enthalten, aber Implementierungsdetails der API-Dienste selbst werden in der Regel ausgelassen. ⓘ
Einschränkungen und Beschränkungen bei der Verwendung der API werden ebenfalls in der Dokumentation behandelt. So könnte die Dokumentation einer API-Funktion beispielsweise darauf hinweisen, dass ihre Parameter nicht null sein können oder dass die Funktion selbst nicht thread-sicher ist. Da die API-Dokumentation in der Regel sehr umfangreich ist, ist es für die Autoren eine Herausforderung, die Dokumentation auf dem neuesten Stand zu halten und für die Benutzer, sie sorgfältig zu lesen, was zu Fehlern führen kann. ⓘ
Die API-Dokumentation kann mit Metadaten wie Java-Annotationen angereichert werden. Diese Metadaten können vom Compiler, von Werkzeugen und von der Laufzeitumgebung verwendet werden, um benutzerdefinierte Verhaltensweisen oder eine benutzerdefinierte Handhabung zu implementieren. ⓘ
Es ist möglich, API-Dokumentation auf datengesteuerte Weise zu erstellen. Durch die Beobachtung vieler Programme, die eine bestimmte API verwenden, lassen sich die typischen Verwendungen sowie die erforderlichen Verträge und Richtlinien ableiten. Anschließend können Vorlagen verwendet werden, um aus den gewonnenen Daten natürliche Sprache zu generieren. ⓘ
Streit um Urheberrechtsschutz für APIs
2010 verklagte die Oracle Corporation Google, weil das Unternehmen eine neue Java-Implementierung, die in das Android-Betriebssystem eingebettet war, verbreitet hatte. Google hatte keine Erlaubnis zur Vervielfältigung der Java-API erhalten, obwohl die Erlaubnis für das ähnliche OpenJDK-Projekt erteilt worden war. Google hatte sich an Oracle gewandt, um eine Lizenz für seine API auszuhandeln, wurde aber aufgrund von Vertrauensproblemen abgewiesen. Trotz dieser Meinungsverschiedenheit entschied sich Google, den Code von Oracle zu verwenden. Richter William Alsup entschied in der Rechtssache Oracle gegen Google, dass APIs in den USA nicht urheberrechtlich geschützt werden können und dass ein Sieg von Oracle den Urheberrechtsschutz auf eine "funktionale Reihe von Symbolen" ausgedehnt und das Urheberrecht für einfache Softwarebefehle erlaubt hätte:
Würde man Oracles Forderung zustimmen, könnte jeder eine Version eines Codes urheberrechtlich schützen lassen, um ein System von Befehlen auszuführen, und damit alle anderen davon abhalten, seine verschiedenen Versionen zu schreiben, um dieselben Befehle ganz oder teilweise auszuführen. ⓘ
Das Urteil von Alsup wurde 2014 in der Berufung vor dem Court of Appeals for the Federal Circuit aufgehoben, obwohl die Frage, ob eine solche Verwendung von APIs eine faire Nutzung darstellt, ungelöst blieb. ⓘ
Im Jahr 2016 entschieden die Geschworenen nach einer zweiwöchigen Verhandlung, dass Googles Neuimplementierung der Java-API eine faire Nutzung darstellt, aber Oracle versprach, gegen die Entscheidung Berufung einzulegen. Oracle gewann seine Berufung, und das Bundesberufungsgericht entschied, dass Googles Nutzung der APIs nicht als faire Nutzung gilt. Im Jahr 2019 legte Google beim Obersten Gerichtshof der Vereinigten Staaten Berufung gegen die Urteile zur urheberrechtlichen Zulässigkeit und zur fairen Nutzung ein, und der Oberste Gerichtshof gab die Revision frei. Aufgrund der COVID-19-Pandemie wurde die mündliche Anhörung in diesem Fall auf Oktober 2020 verschoben. ⓘ
Der Fall wurde vom Obersten Gerichtshof mit 6:2 zugunsten von Google entschieden. Richter Stephen Breyer vertrat die Meinung des Gerichts und erwähnte an einer Stelle, dass "der deklarierende Code, wenn er überhaupt urheberrechtsfähig ist, weiter als die meisten Computerprogramme vom Kern des Urheberrechts entfernt ist." Das bedeutet, dass der in APIs verwendete Code in Bezug auf den Urheberrechtsschutz eher mit Wörterbüchern als mit Romanen vergleichbar ist. ⓘ
Beispiele
- ASPI für SCSI-Geräteschnittstellen
- Cocoa und Carbon für den Macintosh
- DirectX für Microsoft Windows
- EHLLAPI
- Java-APIs
- ODBC für Microsoft Windows
- OpenAL plattformübergreifende Sound-API
- OpenCL plattformübergreifende API für die allgemeine Datenverarbeitung für CPUs und GPUs
- Plattformübergreifende Grafik-API OpenGL
- OpenMP-API, die plattformübergreifende Shared-Memory-Multiprocessing-Programmierung in C, C++ und Fortran auf vielen Architekturen, einschließlich Unix- und Microsoft Windows-Plattformen, unterstützt.
- Server-Anwendungsprogrammierschnittstelle (SAPI)
- Einfache DirectMedia-Schicht (SDL) ⓘ
Einteilung nach Typklassen
Programmierschnittstellen lassen sich in folgende Typklassen einteilen:
- funktionsorientiert (z. B. Dynamic Link Library)
- dateiorientiert (z. B. Gerätedateien unter Unix)
- objektorientiert (z. B. ActiveX-DLLs)
- protokollorientiert (z. B. FTP) ⓘ
Funktionsorientierte Programmierschnittstellen
Funktionsorientierte Programmierschnittstellen kennen nur Funktionen mit oder ohne Rückgabewert als Mittel der Kommunikation. Dabei wird fast immer das Konzept der Handles verwendet. Man ruft eine Funktion auf und bekommt ein Handle zurück. Mit diesem Handle lassen sich weitere Funktionen aufrufen, bis abschließend das Handle wieder geschlossen werden muss. ⓘ
Dateiorientierte Programmierschnittstellen
Dateiorientierte Programmierschnittstellen werden über die normalen Dateisystemaufrufe open, read, write und close angesprochen. Sollen Daten an ein Objekt gesendet werden, werden diese mit write geschrieben, sollen welche empfangen werden, werden sie mit read gelesen. Unter UNIX ist dieses Prinzip bei der Ansteuerung von Gerätetreibern weit verbreitet. ⓘ
Objektorientierte Programmierschnittstellen
Objektorientierte Programmierschnittstellen verwenden Schnittstellenzeiger und sind damit deutlich flexibler als die funktionsorientierten Programmierschnittstellen. Häufig wird eine Typbibliothek mitgegeben. ⓘ
Protokollorientierte Programmierschnittstellen
Protokollorientierte Programmierschnittstellen sind unabhängig vom Betriebssystem und der Hardware. Allerdings muss das Protokoll stets neu implementiert werden. Um diesen Aufwand zu minimieren, wird die protokollorientierte Schnittstelle durch eine funktions- oder interfaceorientierte Schnittstelle gekapselt. Man kann hier weiterhin zwischen allgemeinen (z. B. SOAP) und anwendungsspezifischen (z. B. SMTP)-Protokollen unterscheiden. ⓘ
Einteilung nach Entwicklungsstufen
Bei Programmierschnittstellen für Anwendungssoftware wird darüber hinaus auch nach Entwicklungsstufe unterschieden. Ausgangspunkt dieser Unterscheidung ist die Beobachtung, dass sich Operationen der Programmierschnittstelle oft erst im Laufe der Zeit herausentwickeln. Von großer Wichtigkeit ist dabei, ob in früheren Versionen der Programmierschnittstelle verfügbare Operationen auch in allen Folgeversion noch vorhanden sind und auch dieselbe Bedeutung haben. Bei einer stabilen Schnittstelle braucht die Anwendung nicht mehr geändert zu werden. Unterschieden wird zwischen sich entwickelnden (engl. evolving) und stabilen Programmierschnittstellen (engl. stable API). Als Refactoring wird die Fortentwicklung einer Programmierschnittstelle bezeichnet, die keine Änderungen in den Anwenderprogrammen nach sich zieht. ⓘ
Bedeutung
Das Vorhandensein einer gut dokumentierten Programmierschnittstelle (API) kann ein erheblicher Wettbewerbsvorteil für ein Software- oder ein die Software enthaltendes Hardware-Produkt sein – da auf diese Weise andere Softwarefirmen oder freiberufliche Programmierer in die Lage versetzt werden, zusätzliche Software für dieses System zu erstellen. Mit dem Angebot zusätzlicher Programme von Drittanbietern steigt wiederum die Attraktivität des Ausgangssystems, etwa eines Computer-Betriebssystems, einer Spielkonsole oder einer Smartphone-Familie. Die Geschäftspolitik bezüglich dieser Schnittstelle kann damit über den kommerziellen Erfolg einer Software und gegebenenfalls auch der zugehörigen Hardware entscheiden. So verlangen manche Software-Anbieter erhebliche Geldbeträge für die zugehörige, notwendige Dokumentation, was eine Eintrittsbarriere für interessierte Programmierer darstellt. Auch kann vorgesehen sein, dass auf die API nur mit einem teuer zu erwerbenden Software-Entwicklungssystem zugegriffen werden kann. ⓘ
Ein weiterer Faktor für den Erfolg kann die oben erwähnte Langzeit-Stabilität der API sein, denn bei häufigen Änderungen ist auch der Programmierer einer Zusatzanwendung jedes Mal zur Änderung seiner Software gezwungen, damit sie weiter funktioniert. Dies kann erheblichen Arbeitsaufwand und damit Kosten verursachen, was die Entwicklung kommerziell weniger attraktiv macht. ⓘ