APIs spielen eine zentrale Rolle bei der Digitalisierung. Extern angeboten, ermöglichen sie das Erschaffen von Ökosystemen und neuen Geschäftsmodellen. Unternehmen wollen gerne selbst als Plattform gesehen werden, auch hier sind APIs unerlässlich. Intern, innerhalb der Unternehmen, dienen APIs nicht nur der Vernetzung unterschiedlicher IT-Systeme, sondern ermöglichen im Optimalfall auch den schnellen, programmatischen Austausch zwischen ganzen Domänen.
Wenn es um das Design von APIs geht, kommt diese Wichtigkeit oft nicht zum Tragen: Die Innensicht der IT-Systeme wird nach außen getragen, es fehlt der Fokus auf die Personengruppe, die die API nutzen wird – und die Frage, welches Problem überhaupt gelöst werden soll, wird nicht beantwortet.
Unter API Experience versteht man die Anwendung von Consumer-Centric- und UX-Methoden auf das Thema API. Dafür werden zum Beispiel die Ideen des Design-Sprints und Design Thinking adaptiert, um eine API zu schaffen, die den Anforderungen der Konsumenten genügt. Nachdem man das für einige APIs durchgeführt hat, lassen sich daraus grundsätzliche Guidelines für APIs ableiten, spezifisch für den eigenen Kontext. Generische Guidelines können dabei als Grundlage dienen, sollten aber zwingend an die eigene Situation angepasst werden, zum Beispiel an verwendete Architektur- und Technologiekonzepte wie REST vs. Messaging. Konzepte wie Paging, Filtering, der Umgang mit großen Payloads oder langlaufenden Operationen sowie Rate Limiting sind nicht in allen Kontexten sinnvoll.
Bevor man sich konkret über die API und deren Ausgestaltung Gedanken macht, muss geklärt sein, in welcher Rolle man selbst in der API Economy auftritt: Bin ich Anbieter oder vor allem Nutzer? Biete ich meine APIs öffentlich für alle an, nur für eine begrenzte öffentliche Nutzerschaft oder sogar nur intern? Welche Mehrwerte will ich meinen Nutzern anbieten? Hier kommen wir wie schon beim Platform Engineering oder Data Mesh zu dem Punkt, etwas „as a Product“ zu betrachten, in diesem Fall eine API. Themen wie Ownership, Dokumentation und Messen der API, z. B. mittels eines API-Gateway und -Catalog, fließen also auch hier mit ein.
Der zentrale Teil einer API ist das Datenmodell. Dieses sollte gemeinsam mit den Konsumenten beschrieben werden. Ein möglicherweise bereits vorhandenes Datenmodell, beispielsweise aus einem Data Catalog oder einem Master Data Management, kann dabei als Basis genommen werden. Dieses Vorgehen bedeutet aber nicht, dass zwingend „API First“ gearbeitet werden sollte. Im Gegenteil, für viele Anbieter ist das deutlich schwieriger, da sie aufgrund von Legacy-Systemen, die die Anfragen am Ende beantworten, Einschränkungen haben.
Mit der API Experience sollen der Nutzer und der Nutzen wieder mehr in den Vordergrund gerückt und Organisationen befähigt werden, konsistent und mit wenig Aufwand gute APIs bereitzustellen. Insbesondere für Endpunkte, die von außerhalb der Domäne oder Organisation genutzt werden, eine sinnvolle Sache.
Dieser Artikel erschien am 03.02.2023 im Rahmen des codecentric-Innovations-Newsletters. Wenn ihr immer direkt über die neusten IT-Trends und -Techniken informiert sein wollt, könnt ihr den Newsletter hier abonnieren.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Matthias Niehoff
16.6.2023 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Matthias Niehoff
Head of Data
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.