Programmierschnittstelle

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Application Programming Interface)
Wechseln zu: Navigation, Suche
Standardisierte Programmierschnittstellen (APIs) über unterschiedliche Betriebssysteme sorgen für Quelltextkompatibilität, d.h. Quellcode kann ohne Anpassungen für die jeweiligen Systeme erfolgreich compiliert werden.

Eine Programmierschnittstelle, genauer Schnittstelle zur Anwendungsprogrammierung, oder oft kurz API (englisch application programming interface, wortwörtlich ‚Anwendungs­programmier­schnittstelle‘), 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.[1] 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 bekannten Computer-Betriebssystems Microsoft Windows, dass externe Firmen überhaupt erst Software für dieses Betriebssystem entwickeln können.

Heutzutage stellen auch viele Internetdienste Programmierschnittstellen zur Verfügung. Im weiteren Sinne wird die Schnittstelle jeder Bibliothek (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.

Einteilung nach Typklassen[Bearbeiten]

Programmierschnittstellen lassen sich in folgende Typklassen einteilen:

Funktionsorientierte Programmierschnittstellen[Bearbeiten]

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[Bearbeiten]

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[Bearbeiten]

Objektorientierte Programmierschnittstellen verwenden Schnittstellenzeiger und sind damit deutlich flexibler als die funktionsorientierten Programmierschnittstellen. Häufig wird eine Typbibliothek mitgegeben.

Protokollorientierte Programmierschnittstellen[Bearbeiten]

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[Bearbeiten]

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.[2]

Bedeutung[Bearbeiten]

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 Spielekonsole 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 mit dem Basissystem funktioniert. Dies kann erheblichen Arbeitsaufwand und damit Kosten verursachen, was die Entwicklung kommerziell weniger attraktiv macht.

Beispiele[Bearbeiten]

Die Entwicklungsumgebung Xcode, mit der auf die API des Mobilbetriebssystems 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 spätestens seit dem Erfolg des Android-Betriebssystems keine Exklusivität mehr besitzt.[3]

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 zum Single Unix Specification-Standard der Open Group zu verzeichnen. Dieser Standard ist offen, im Internet frei verfügbar und jedermann kann Vorschläge dazu einreichen.

Siehe auch[Bearbeiten]

Literatur[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. Oliver Thoma: Mac OS X 10.4 Tiger. Google Bücher. 2006. Abgerufen am 27. März 2011.
  2. Danny Dig, R. Johnson: How do APIs evolve? A story of refactoring. In Journal of Software Maintenance and Evolution. Research and Practice. Wiley, Chichester, New York 2006. S. 1−26.
  3. All Your Apps Are Belong to Apple: The iPhone Developer Program License Agreement. Electronic Frontier Foundation. 9. März 2010. Abgerufen am 17. April 2010.