API

Eine API ist die definierte Art, wie eine Software mit einer anderen redet. Sie sagt: Hier sind die Dinge, um die du mich bitten kannst, hier ist genau, wie du fragst, und hier ist, was du zurückbekommst. Der ganze Sinn ist, dass der Aufrufer nicht wissen muss, wie die Arbeit intern erledigt wird, nur was er senden und was er erwarten soll. Die Wetter-App auf deinem Telefon weiß nicht, wie der Wetterdienst funktioniert. Sie kennt nur die API, sendet eine Anfrage und bekommt eine Vorhersage.

Die Kernidee ist der Vertrag. Beide Seiten einigen sich auf die Form der Anfragen und Antworten, und solange dieser Vertrag hält, kann jede Seite ihr Innenleben frei ändern. Die zwei gängigen Stile, von denen man hört, sind REST, das alles als Ressourcen modelliert, die man über Standard-Webanfragen liest und schreibt, und das der Standard für die meisten Web- und Mobile-Backends ist, und GraphQL, das dem Aufrufer erlaubt, in einer Anfrage genau die Felder zu erbitten, die er will. Beide sind nur disziplinierte Arten, denselben Vertrag zu definieren.

API-Design ist eine der langlebigsten Entscheidungen, die man trifft. Internen Code kann man an einem Wochenende refaktorieren. Bei einer öffentlichen API hängt fremde Software von genau ihrer Form ab, also brechen Änderungen deren Integrationen, was bedeutet, dass man sie oft gar nicht ändern kann ohne eine schmerzhafte Versionierung. Eine saubere, gut benannte, konsistente API altert gut. Eine schludrige wird zu einer dauerhaften Steuer, die man bei jeder künftigen Änderung zahlt. Wir behandeln API-Design als erstklassigen Teil der Softwareentwicklung, nicht als nachträglich angeschraubten Gedanken.

Die ehrliche Einschätzung: Die meisten “die Integration ist ein Albtraum”-Klagen lassen sich auf eine API zurückführen, die in Eile entworfen wurde, um ein Feature zu liefern, und dann zehn tragen musste. Investiere früh die Zeit in den Vertrag. Das ist der Teil, den du später am wenigsten ändern kannst.