Über Designfragen hinaus zählt der Gesamtkontext einer Schnittstelle Regeln für die API-Entwicklung

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Windhoff Group

Windhoff Group

Schnittstellen-Entwicklung ist kein Ad-hoc-Projekt, sondern braucht in jeder Phase genügend Zeit, um alle aktuellen und zukünftigen Szenarien zu beleuchten. Schließlich geht es um einen effizienten, langfristigen und nutzbaren Einsatz der Schnittstelle im jeweiligen Anwendungsfall.

Programmierschnittstellen oder kurz APIs allein als Vehikel zum Datenaustausch zwischen Systemen zu betrachten, wird ihrer Rolle längst nicht mehr gerecht. In einer vernetzten Welt digitaler Strukturen und Prozesse dienen Schnittstellen dem Anreichern von KI mit Daten, sie analysieren und optimieren Geschäftsvorgänge und vieles mehr. Es gibt also die unterschiedlichsten Anwendungsszenarien. Damit eine API genau den ihr zugedachten Zweck erfüllt, sind einige Grundlagen zu beachten.

Welche Systeme sind am Datenaustausch überhaupt beteiligt? Die Frage scheint banal, doch genau mit ihr geht es los. Neben den beiden Systemen, zwischen denen die API die Kommunikation herstellen soll, gibt es diverse Middleware und weitere Stationen auf dem Weg zwischen den Schnittstellenpartnern.

Nicht alle von ihnen können miteinander sprechen, weshalb ggf. zusätzliche Komponenten benötigt werden. Typisches Beispiel im Bereich der Webservices wäre hier die Konvertierung von SOAP in das REST-Format, die sich mit Tools wie Orchestra durchführen lässt.

Sind die Schnittstellen sicher?

In der vernetzten Welt sind Schnittstellen ein gefundenes Fressen und scheinbar leichte Beute für Kriminelle. Schon bei der Architektur und Entwicklung der Schnittstellen sind deshalb Sicherheitsvorkehrungen zu treffen, um Risiken zu minimieren. Basisarbeit ist der Austausch spezieller Zertifikate. Auf Infrastrukturebene dienen Token-basierte Verfahren Oauth und Oauth 2.0 oder Credential-basierte Methoden wie Basic der Authentifizierung.

Das ATT&CK-Framework (Adversarial Tactics, Techniques, and Common Knowledge Framework) zählt aktuell 14 Kategorien, die Angreifer nutzen, um ihre Ziele zu erreichen – von Command-and-Control-Angriffen bis hin zur Privilege Escalation. Werden diese schon bei der Architektur und Entwicklung der Schnittstellen beachtet, lassen sich potenzielle Sicherheitslücken bereits im Vorfeld proaktiv schließen.

Innerhalb der Schnittstelle kommt es darüber hinaus auf die saubere Definition einzelner Operationen sowie des API-Mappings an. Sind überhaupt alle Operationen erforderlich? Dass mit dem jeweiligen Schnittstellenpartner die Rahmenbedingungen zu klären sind, versteht sich von selbst, denn es macht eben einen Unterschied, ob eine Master-Slave- oder eine Push-Push-Schnittstelle entwickelt wird, ob sie synchron oder asynchron verläuft etc.

Den Mittelweg zwischen „grob“ und „granular“ finden

Schnittstellen zu definieren ist eine Gratwanderung. Weder sollte man zu grob vorgehen, noch zu granular. Auf welcher Detailebene letztlich gearbeitet wird, hängt von der Art der Schnittstelle ab. Für das bloße Importieren von Assets genügt mitunter schon eine Aktion zum Erstellen und Updaten der Assets.

Vorab gilt es genau zu prüfen, ob für den Import tatsächlich Daten zu löschen sind. Wurden Datensätze aus dem System entfernt (durch Vorsatz oder grobe Fahrlässigkeit), ist es zumeist sinnvoller, die Daten einfach zu deaktivieren oder zu archivieren.

Je offener eine API gestaltet ist und je mehr Operationen sie zulässt, desto mehr Einfallstore bietet sie wiederum potenziellen Angreifern. Das bedeutet, dass auch Sicherheitsaspekte die Schnittstellenarchitektur beeinflussen. Bei der Entwicklung gilt es daher festzulegen, welche Daten sichtbar und welche wann veränderbar sein sollen.

Hier hat sich der Grundsatz „So wenig wie möglich, so viel wie nötig“ bewährt. Hinsichtlich spezieller Kundendaten müssen auch Richtlinien wie die ISO-27000 oder GDPR (General Data Protection Resolution) im Auge behalten werden.

Wie API-Methoden und -Mapping zusammenspielen, ist elementar beim Schnittstellendesign. Nehmen wir als Beispiel den Change in einem Ticketsystem. Dabei handelt es sich um einen in der Regel linearen Prozess, der optimalerweise synchron mit dem jeweiligen Schnittstellenpartner abläuft. Wichtig: Hier können jeweils nur Schnittstellenaufrufe passend zur aktuellen Phase des Changes abgesetzt werden.

Fatal wäre es, wenn der Schnittstellenpartner etwa die eigene Risikobewertung oder Klassifizierung in dieser Implementierungsphase ändern kann – also zu einem Zeitpunkt, zu dem diese Werte bereits feststehen müssen. Doch dafür gibt es eine Lösung: Die Daten werden abgelehnt (im Zweifel sogar der komplette Schnittstellenaufruf mit einem eindeutigen Fehlerhinweis).

Kontext, Anwendungsfall und Nutzen in den Fokus

Die bisher genannten Überlegungen bezogen sich auf das Schnittstellen-Design. Darüber hinaus geht es aber um den Gesamtüberblick und darum, stets Kontext, Anwendungsfall und gewünschten Nutzen der geplanten Schnittstelle im Fokus zu behalten.

Orientierung dabei leisten folgende Fragen: Existieren interne Abhängigkeiten und lässt sich die Schnittstelle nutzen, um etwa Bestellungen für IT-Equipment oder Büromaterial zu tätigen? Wer arbeitet mit der Schnittstelle? Eine weitere Rolle spielen externe Abhängigkeiten: Erhalten Kunden mehr Usability, zum Beispiel durch Chatbots oder Selfservice mit anschließender Ticketerstellung? Und wer arbeitet dann mit der Schnittstelle?

APIs bieten Anwenderinnen und Anwendern neuen Komfort und können Unternehmen zugleich helfen, Kosten einzusparen. Letzteres hängt jedoch davon ab, wie intensiv die Schnittstelle zum Einsatz kommt. Viel Aufwand in eine API zu stecken, die dann nur von 20 Personen genutzt wird, dürfte sich kaum lohnen. Je höher also die Userzahl, desto besser sieht die Kosten-Nutzen-Rechnung aus.

Visualisierungen helfen dabei, einen Gesamtüberblick zu erhalten, zum Beispiel in Form eines Detailplans, der Mengengerüste beziffert sowie Kosten abwägt, mit allen eingesetzten Komponenten, Anwendern und weiteren Faktoren. Stimmt die Kosten-Nutzen-Rechnung, ist eine gut gemachte Schnittstelle ein sinnvolles Investment, dass sich schon bald bezahlt macht.