Application Programming Interfaces (API) – #BreakingMyTwitter

Am 16.08. werden drastische Änderungen an der Twitter-API vorgenommen und man munkelt, es wäre der Tag an dem Twitter stirbt…aber stimmt das? Und was ist eigentlich eine API?

APIs sind seit dem Web 2.0 wohl sowas wie ein Allheilmittel und ein must-have für die Investorengewinnung der Jahrtausendwende. Ein Vergleich lässt sich möglicherweise mit der Blockchain-Technologie von heute ziehen – und obwohl ohne APIs heute einiges nicht funktionieren würde, wissen viele gar nicht wofür man sie braucht und was sie machen.

APIs – also Application Programming Interfaces – dienen als eine Art Brücke zwischen Webseiten, Programmen, Festplatten und sonstiger Hardware diverser Anbieter, die Daten und Inhalte tauschen, teilen und weiter verarbeiten möchte. Diese dienen als Schnittstelle, damit zwei verschiedene Systeme miteinander agieren können, vergleichbar mit einem Dolmetscher, Paartherapeuten oder Mediator. So sind Angebote wie z.B. App-Stores oder Desktop-Clients (beA ;)) oder dass externe Personen/Unternehmen Anwendungen erstellen können, die unter Windows oder MacOS, zum Teil sogar systemübergreifend laufen können, (sog. Quelltextkompatibilität) überhaupt möglich.

User Interface = API? & die Grundlagen

Jede Anwendung besteht aus einem Fronted-User Interface, also aus dem für Menschen erkennbaren Gesicht der Anwendung, sowie aus einem Backend, dem Gehirn. Schließlich interessiert uns im Alltag der Algorithmus, der hinter Google steckt nicht wirklich; wir wollen nur, dass wir dank einer einfachen Oberfläche schnell unsere Suchergebnisse finden können. Ob dabei Wahrscheinlichkeiten berechnet, Werbezahlungen für die Trefferquoten einfließen und Datenbanken in Millisekunden abgesucht werden, ist uns in der Regel egal. So werden die Programmoberflächen bis ins kleinste Detail perfektioniert und anwenderorientiert, mittels der Programmiersprachen HTML, CSS und Javascript(u.a) visuell aufbereitet.

Stellen wir uns einfach vor was passieren würde, wenn man den Inhalt des Schönfelders in einen Backend übersetzen und dem Ganzen ein User Interface aufsetzen würde: eine Vielzahl von verständlichen, im einfachen Design dargestellten Funktionen auf einer einfachen Anwenderoberfläche; im Grunde genau das, was Expertensysteme heute machen.

Eine gleichwertige Oberfläche zum User Interface gibt es nun auch für Software; es nennt sich API und unterscheidet sich dadurch, dass es in maschinenlesbarer Form einen Zugriff auf den Backend und so die Verarbeitung von Daten= Funktionen möglich macht.

Die Schwierigkeit liegt darin, dass während das User Interface für einen menschlichen Nutzer von einem Menschen designed wurde, so werden APIs von Menschen für Maschinen programmiert; sie müssen aber auch gleichzeitig für einen Entwickler verständlich sein, da er mit diesen zukünftig arbeiten möchte oder muss. APIs sind schließlich dafür da, um in komprimierter Form auf die Daten zugreifen zu können. Hierfür muss man sie und ihre Struktur erstmal verstehen, ohne hierfür jedes Mal einen Informatiker-Staudinger (falls es den gäbe)- zur Hand nehmen zu müssen. Die Lösung heißt: Standardisierung.

Standardisierung und einheitliche Form

Sollten APIs jeweils immer inhaltlich und strukturell komplett neu entworfen werden, bräuchte jeder Entwickler, um diese Schnittstellen verwenden zu können, jeweils immer eine neue Schulung, eine Anleitung, ein Handbuch. So müssten Entwickler jedes Mal zum Kommentar greifen, um mit einer neuen API arbeiten zu können. Während also der Gesetzgeber im Strafrecht mehr oder weniger immer denselben Aufbau verwendet: Tatbestand, Rechtsfolge bzw. Strafmaß, Versuchsstrafbarkeit und Regelbeispiele – so bedienen sich APIs bei Verwendung diverser Standards auch bestenfalls einer einheitlichen Struktur.

Je nachdem, ob der Designer sich in die Vorgabe eines der Gutachten-/Urteilsstil ähnelnden Struktur zwingen oder sich selbst, wie in einer Kolumne, weniger Strukturvorgaben vorschreiben lassen will, wird er zu den von links nach rechts in der Reihenfolge der Titel genannten Standards greifen. So lässt die Struktur von SOAP kaum gestalterische Freiheiten zu, während RCP als die erste und somit einfachste API-Schnittstelle darstellt; und als solche nur eine einzige Funktion das Ausführen von Code auf einem anderen Server, bezweckt.

Zur Differenzierung

Während wir unterschiedliche Normen(-absätze) unterscheiden, z.B. Rechtsgrundverweis, Rechtsfolgenverweis, Regelbeispiel, Tatbestand, so dienen die verschiedenen Formen von WEB APIs auch unterschiedlichen Zwecken. So wird zwischen internen und externen, Plattform-APIs, sowie Authentifizierungs- und Autorisierungs-APIs unterschieden.

Interne APIs

… sind wie die einzelnen Anspruchsgrundlagen im Gutachten, denn am Ende besteht ein Code genauso wie unser Gutachten aus einzelnen Modulen. Je besser der Entwickler den Code modularisiert hat, je besser also einzelne Bereiche von den anderen abgrenzen lassen (z.B. Prüfung des Eigentumserwerbes nach § 929, 1 BGB), desto eher kann man von einer Schnittstelle reden, auf die später die anderen Module zugreifen.

Die entsprechenden Parallelen finden sich im Gutachten, in dem man im weiteren Verlauf auf die oben festgestellte Eigentümerstellung hinweist: „A ist Eigentümer, s.o.“

Denn je modularer ein Code am Ende ist, desto einfacher lassen sich die Funktionen später untereinander verbinden und umso eher wird die gesamte Komplexität des verringert…ganz einfach: Sie können entweder einmal sauber die wirksame Stellvertretung eines potenziellen Stellvertreters prüfen und im späteren Verlauf immer wieder auf die obige Prüfung verweisen oder Sie prüfen es jedes Mal, wenn es einschlägig ist neu.

Interne APIs, bis zur Perfektion getrieben, nennen sich SOA= Service-Orientated Architectures –  also Systeme, die sich ihrerseits in einzelne Teilsysteme zerlegen lassen und möglicherweise ihrerseits sogar mit weiteren APIs kommunizieren.

Externe APIs

… sind diejenigen, die man im allgemeinen Sprachgebrauch meint.

Ein Beispiel: Die diversen Desktopanwendungen von WhatsApp, die sich alle der Click-to-Chat API von WhatsApp bedienen, nachdem hier kein offizielles externes API existiert.
Im Vergleich: Facebook-Messenger, Telegram, Viber, Slack etc.; alle, für die eine entsprechende Desktopanwendung existiert, bedienen in der Regel eine externe API.

Plattform APIs

Als Schnittstellen für den Zugriff auf Daten einer anderen Webseite oder Plattform werden sog. Plattform APIs herangezogen. Diese beinhalten nicht nur eine „virtuelle Brücke“, um Verweise bilden zu können, sondern beinhalten diverse Funktionen, um die User Interfaces einer Plattform in die User Interfaces einer Anwendung integrieren zu können. So sind diverse Applikationen, sog. Plug-Ins überhaupt möglich, z.B. die diversen Ad-Blocker und sonstige Zusatzfunktionen der Webbrowser.

Authentifizierungs- und Autorisierungs-APIs

Eine Sonderform von WEB APIs sind die Schnittstellen zur Identifikation und Autorisierung von Benutzern. So wird die Anmeldung anhand der Facebookdaten für die Benutzung von Instagram möglich oder die Bezahlung über Amazon bei einem von Amazon an sich unabhängigen Shops, ohne die entsprechenden Daten erneut vollumfänglich eingeben zu müssen.

unterschiedliche Typklassen

Eine weitere Differenzierung lässt sich auch anhand der Typklassen vornehmen. So lassen sich funktions-, datei-, objekt- oder protokollorientierte Typklassen von Schnittstellen unterscheiden. Außerdem hängt die Funktionsweise bzw. Qualität der Schnittstellen auch von deren Stabilität und Entwicklungsstufe ab. So entstehen Funktionen oft erst im Laufe der Entwicklung, sodass diverse Prioritäten und Funktionen je nach Folgeversion unterschiedlich sein können. Im Zuge dessen gewinnt die Bezeichnung „Refactoring“ eine wichtige Bedeutung – also die Fortentwicklung einer Schnittstelle ohne Änderung des Programmverhaltens. Oft steht der Begriff bloß für die Verbesserung der Quellcodestruktur.

Rechtliche Relevanz

Schön und gut, aber wieso sind diese Informationen für mich als Jurist relevant? Abgesehen davon, dass es nie schadet die Grundlagen zu kennen, finde ich persönlich die marken- bzw. wettbewerbsrechtliche Relevanz von APIs bemerkenswert.

Es ist schliesslich so: Je strukturierter, besser dokumentierter und aus langer Sicht stabiler eine Programmierschnittstelle ist, umso eher kann man davon ausgehen, dass ein freiberuflicher Programmierer oder sogar ein Startup eher damit arbeiten wird und diese sich somit einen Wettbewerbsvorteil verschaffen kann. Gleichzeitig gilt aber auch: je mehr Software die Schnittstelle verwendet, desto eher wird  sich diese ausbreiten und somit die eigene Attraktivität steigern; frei nach dem Prinzip der Netzwerkeffekte auf Entwicklerebene. So ist auch nicht verwunderlich, dass die Verwendung mancher Schnittstellen kostspielig und an diversen sonstigen Bedingungen geknüpft ist, z.B. Geheimhaltungsverpflichtung oder Lizenzgebühren z.B. von Google Maps. Diese Gebühren wird man aber im Zweifel entrichten, um auf die umfassende Datenmenge zugreifen zu können, da andere Alternativen: z.B. eigene Satelliten, neue Systeme, möglicherweise nicht so attraktiv erscheinen, nicht so aktuell, schnell, zuverlässiger sogar noch kostspieliger sind. Es stellt sich nun noch die Frage, ob dasselbe Phänomen auch für Twitter gelten wird, sobald ab dem 16.08 der Zugang bzw. die Nutzungsmöglichkeiten für Drittanbieter eingeschränkt werden. Stirbt Twitter oder sterben die Drittanwendungen? Was meint ihr?

Diskutiert wird übrigens unter dem Hashtag: #BreakingMyTwitter

Quellen und weiterführende Hinweise

Was Banken mit APIs zu tun haben und warum sie ab Mitte 2019 anderen Firmen eine eigene API anbieten müssen

Der Tag an dem Twitter stirbt

https://blog.apisyouwonthate.com/understanding-rpc-rest-and-graphql-2f959aadebe7

http://apibusters.com/003-why-hypermedia

https://www.gruenderszene.de/allgemein/web-apis-ein-nicht-technischer-erklarungsversuch

https://de.wikipedia.org/wiki/Web_2.0

https://www.dpunkt.de/common/leseproben//12326/4_Kapitel%208.pdf

https://www.heise.de/developer/artikel/Federlesen-20-Stabile-APIs-fuer-eine-nachhaltige-Entwicklung-2577968.html

http://static.scribd.com/docs/908bil5xonqxe.pdf

 

Teile diesen Beitrag

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.