APIs ermöglichen die Kommunikation zwischen verschiedenen Systemen und erleichtern die Integration von Anwendungen. Ob beim Abrufen von Wetterdaten, dem Zugriff auf Zahlungsdienste oder dem Streamen von Videos – APIs sind das Rückgrat digitaler Dienste. Doch mit der steigenden Nutzung von APIs wachsen auch die Herausforderungen im Hinblick auf deren Performance und Sicherheit. Hier kommen Rate Limiting und Throttling ins Spiel, um eine stabile und sichere Nutzung von APIs zu gewährleisten und gleichzeitig einen fairen Zugriff für alle Nutzer sicherzustellen. Was ist Rate Limiting? Rate Limiting bezeichnet die Begrenzung der Anzahl von Anfragen, die ein Nutzer oder ein System innerhalb eines bestimmten Zeitraums an eine API senden darf. Dies wird genutzt, um Ressourcen fair zu verteilen, Missbrauch zu verhindern und die Serverlast zu kontrollieren. Ein Zahlungsanbieter erlaubt beispielsweise pro Benutzer maximal 100 API-Anfragen pro Minute. Würde ein Nutzer versuchen, innerhalb einer Minute 200 Anfragen zu senden, würden die über das Limit hinausgehenden Anfragen blockiert. Dadurch wird sichergestellt, dass kein einzelner Nutzer die API übermäßig belastet oder gar missbraucht. Erprobte Verfahren zur Lastbegrenzung in APIs: Fixed Window Limiting: Eine feste Anzahl an Anfragen pro Zeiteinheit wird erlaubt. Eine API erlaubt maximal 1.000 Anfragen pro Stunde. Wenn das Limit erreicht ist, werden weitere Anfragen bis zur nächsten Stunde blockiert. Sliding Window Limiting: Die Anfragen werden innerhalb eines gleitenden Zeitfensters gezählt. Falls eine API ein Limit von 100 Anfragen pro Minute hat, werden nicht alle Anfragen zu einer festen Minute zurückgesetzt, sondern kontinuierlich neu berechnet. Token Bucket: Anfragen werden nur akzeptiert, wenn genügend Token im Bucket verfügbar sind. Ein System kann 10 Token pro Sekunde bereitstellen, und jede Anfrage verbraucht ein Token. Wenn der Bucket leer ist, müssen Nutzer warten, bis sich neue Token ansammeln. Leaky Bucket: Anfragen werden gleichmäßig verarbeitet, um Lastspitzen zu verhindern. Anstatt dass 1.000 Anfragen sofort bearbeitet werden, werden sie nach und nach verarbeitet, sodass das System stabil bleibt. Was ist Throttling? Throttling ist eine spezielle Form des Rate Limitings, bei der die API-Performance dynamisch angepasst wird, um die Systemstabilität zu gewährleisten. Statt Anfragen sofort abzulehnen, wenn das Limit erreicht ist, sorgt Throttling dafür, dass API-Anfragen verlangsamt oder in Warteschlangen gestellt werden. Ein praxisnahes Beispiel für Throttling ist der Ticketverkauf für große Veranstaltungen, wie Konzerte oder Sportereignisse. Wenn ein neuer Ticketverkauf startet, strömen Millionen von Nutzern gleichzeitig auf die Plattform. Um zu verhindern, dass das System überlastet wird, setzt die Plattform ein Throttling ein: Nutzer werden in virtuelle Warteschlangen eingereiht, und ihre Anfragen werden nach und nach bearbeitet. So bleibt das System stabil und der Verkauf läuft geordnet ab, ohne dass das System zusammenbricht. Unterschiede zwischen Rate Limiting und Throttling Rate Limiting und Throttling verfolgen beide das Ziel, die Nutzung von APIs zu regulieren und Überlastungen zu vermeiden. Der wesentliche Unterschied liegt jedoch in der Art und Weise, wie diese Begrenzungen umgesetzt werden. Rate Limiting arbeitet mit festen Obergrenzen und blockiert Anfragen, sobald das festgelegte Limit überschritten wird. Dies ist besonders nützlich, um Missbrauch zu verhindern, beispielsweise durch Bots, die eine API übermäßig belasten könnten. Sobald ein Nutzer die maximale Anzahl an zulässigen Anfragen erreicht hat, erhält er eine Fehlermeldung und muss warten, bis das Limit wieder zurückgesetzt wird. Throttling hingegen setzt nicht auf absolute Sperrungen, sondern verlangsamt die Bearbeitung von Anfragen oder stellt sie in eine Warteschlange. Dadurch kann das System flexibel auf Lastspitzen reagieren, ohne Nutzer sofort auszuschließen. Während Rate Limiting also eine harte Grenze setzt, sorgt Throttling für eine dynamische Anpassung der Lastverteilung. Beide Mechanismen haben ihre Daseinsberechtigung und werden je nach Anwendungsfall kombiniert, um APIs sowohl leistungsfähig als auch fair nutzbar zu machen. Warum sind API-Nutzungsbegrenzungen wichtig? APIs sind essenzielle Bestandteile moderner Softwarelandschaften und ermöglichen die Kommunikation zwischen verschiedenen Systemen. Doch ohne geeignete Nutzungsbegrenzungen können sie schnell zur Schwachstelle werden. Rate Limiting und Throttling sind daher unverzichtbare Maßnahmen, um Sicherheit, Stabilität und Effizienz sicherzustellen. 1. Schutz vor Missbrauch und DDoS-Angriffen Ohne Begrenzungen könnten böswillige Akteure unzählige Anfragen an eine API senden, um diese zu überlasten oder gezielt außer Betrieb zu setzen. Ein klassisches Beispiel ist ein DDoS-Angriff (Distributed Denial of Service), bei dem ein Server mit Anfragen geflutet wird, bis er nicht mehr reagiert. Durch ein Anfragelimit, beispielsweise 100 Anfragen pro Minute pro Nutzer, kann ein System solche Attacken frühzeitig erkennen und abwehren. 2. Faire Nutzung der Ressourcen Stellen Sie sich eine API vor, die von einem Unternehmen bereitgestellt wird, um Wetterdaten abzurufen. Ohne Begrenzungen könnte ein einzelner Nutzer Millionen von Anfragen senden und damit die gesamte Serverkapazität beanspruchen, sodass andere Nutzer leer ausgehen. Rate Limiting stellt sicher, dass alle Nutzer gleiche und faire Zugriffsrechte erhalten und keine Einzelperson das System monopolisiert. 3. Verhinderung von Server-Überlastung APIs haben eine begrenzte Kapazität – sowohl hinsichtlich Rechenleistung als auch Speicherverbrauch. Eine E-Commerce-Plattform bietet beispielsweise eine API für Produktanfragen an. Wenn Millionen von Abfragen gleichzeitig auf den Server treffen, könnte das dazu führen, dass der Checkout-Prozess für echte Kunden verlangsamt oder blockiert wird. Rate Limiting hält die API-Leistung stabil und schützt vor unerwarteten Systemausfällen. 4. Überlastung von Backend-Systemen und Datenbanken vermeiden Viele APIs sind eng mit Datenbanken und anderen Backend-Systemen verknüpft. Wenn eine API unkontrolliert genutzt wird, kann dies zu einer erheblichen Belastung der Datenbank führen. Ein Beispiel wäre ein Finanzdienstleister, der eine API für Transaktionsanfragen anbietet. Wenn ein Bot unaufhörlich Kontostände abruft, könnte dies die Datenbank verlangsamen, sodass echte Banktransaktionen verzögert werden. 5. Kosteneffizienz Viele APIs nutzen ein pay-per-use-Preismodell, bei dem jede Anfrage Kosten verursacht. Ein Unternehmen, das eine Cloud-Computing-API nutzt, könnte ohne Begrenzung unbewusst tausende Anfragen pro Sekunde senden – was zu einer enormen Rechnung führt. Durch Limits lassen sich solche unerwarteten Kosten vermeiden. 6. Bessere Benutzererfahrung Wenn eine API durch übermäßigen Traffic überlastet ist, steigen die Ladezeiten für legitime Nutzer. Beispielsweise könnte eine Streaming-Plattform ohne Rate Limiting durch übermäßige API-Anfragen ins Stocken geraten, was sich in ruckelnden Videos und langen Ladezeiten äußert. Eine Begrenzung sorgt für eine gleichbleibend hohe Servicequalität. 7. Schutz vor Credential Stuffing Cyberkriminelle nutzen automatisierte Angriffe, um gestohlene Anmeldeinformationen aus früheren Datenlecks massenhaft zu testen. Dies wird als Credential Stuffing bezeichnet. Ein Angreifer probiert innerhalb weniger Minuten zehntausende Kombinationen von Benutzernamen und Passwörtern aus. Ein Limit von 5 Login-Versuchen pro Minute könnte diesen Angriff frühzeitig stoppen. 8. Verhinderung von API Scraping Unternehmen investieren viel in den Schutz ihrer Daten. Ohne Begrenzungen könnten Bots eine API unkontrolliert abfragen und sensible Informationen extrahieren. Beispielsweise könnte eine API für Immobilienpreise von Wettbewerbern ausgenutzt werden, um systematisch Preisdaten zu stehlen und unfaire Marktvorteile zu erlangen. 9. Schutz vor Brute-Force-Angriffen Brute-Force-Angriffe zielen darauf ab, Passwörter oder API-Schlüssel durch massenhaftes Ausprobieren zu erraten. Ein bekanntes Beispiel ist der Angriff auf Online-Konten: Ohne Begrenzung könnten Millionen von Passwörtern pro Sekunde getestet werden. Ein Limit, das nach mehreren fehlgeschlagenen Versuchen eine kurze Sperrung auslöst, schützt effektiv vor solchen Angriffen. 10. Erkennung verdächtiger Aktivitäten Ein plötzliches, ungewöhnliches Anfragemuster kann ein Hinweis auf einen Angriff oder Missbrauch sein. Beispielsweise könnte eine Banking-API bemerken, dass eine IP-Adresse plötzlich extrem viele Anfragen sendet, um sich Zugriff auf Kontodaten zu verschaffen. Solche Anomalien können durch Limits erkannt und gezielt blockiert werden. 11. Missbrauch von API-Schlüsseln einschränken API-Schlüssel sind oft das Eintrittstor zu einem System. Werden sie kompromittiert, kann ein Angreifer ungehindert Anfragen senden – beispielsweise um massenhaft Daten abzurufen oder betrügerische Transaktionen durchzuführen. Rate Limiting sorgt dafür, dass selbst bei einem gestohlenen Schlüssel der Schaden begrenzt bleibt, indem untypisches Nutzungsverhalten erkannt und gestoppt wird. Best Practices für die Nutzung von Rate Limiting und Throttling Rate Limiting und Throttling sind essenzielle Mechanismen, um die Nutzung von APIs effizient zu steuern und eine Überlastung der Systeme zu verhindern. Sie helfen dabei, Ressourcen fair zu verteilen, Missbrauch zu reduzieren und eine stabile Performance sicherzustellen. In der Regel bieten API-Gateways diese Funktionen out of the box als API-Policies an, sodass sie einfach implementiert und konfiguriert werden können. 1. Klare Limits definieren Es ist entscheidend, dass Nutzer genau wissen, wie viele Anfragen sie innerhalb eines bestimmten Zeitraums senden dürfen. Beispielsweise könnte eine API für Wetterdaten eine Beschränkung von 1.000 Anfragen pro Stunde haben, während eine Finanz-API strengere Limits von 100 Anfragen pro Minute setzt, um Missbrauch zu verhindern. Diese Limits sollten in der API-Dokumentation transparent kommuniziert werden, damit Entwickler ihre Anwendungen entsprechend anpassen können. 2. Fehlermeldungen und Alternativen bereitstellen Wenn Nutzer ein Limit überschreiten, sollte die API klare Fehlermeldungen zurückgeben. Eine gängige Praxis ist die Verwendung des HTTP-Statuscodes 429 (Too Many Requests), kombiniert mit einem Retry-After-Header, der angibt, wann erneut Anfragen gestellt werden können. Zusätzlich können API-Anbieter alternative Lösungen wie Premium-Pläne mit höheren Limits oder zeitlich verzögerte Verarbeitung anbieten, um Nutzern entgegenzukommen. 3. Adaptive Limits nutzen Statische Limits sind nicht immer optimal. Adaptive Rate Limits passen sich dynamisch an die aktuelle Serverauslastung an. Beispielsweise könnte ein Streaming-Dienst unter normalen Bedingungen 5.000 Anfragen pro Stunde erlauben, aber in Spitzenzeiten die Obergrenze auf 3.000 Anfragen senken, um eine Überlastung der Server zu vermeiden. Diese Technik wird oft mit Machine Learning-gestützter Traffic-Analyse kombiniert, um bösartige Anfragen in Echtzeit zu erkennen. 4. Caching und Load Balancing einsetzen Um API-Anfragen zu reduzieren, können Antworten zwischengespeichert (Caching) und Anfragen auf mehrere Server verteilt (Load Balancing) werden. Ein praktisches Beispiel ist ein Nachrichtendienst, der häufig nach den neuesten Schlagzeilen gefragt wird. Statt jede Anfrage an die API weiterzuleiten, kann ein CDN (Content Delivery Network) gespeicherte Antworten für eine kurze Zeit bereitstellen, sodass wiederholte Anfragen nicht die API belasten. 5. API-Schlüssel und Nutzerauthentifizierung verwenden Um Missbrauch zu verhindern und eine gezielte Kontrolle über die Nutzung zu ermöglichen, sollten APIs Schlüssel-basierte Authentifizierung nutzen. Beispielsweise könnte eine Social-Media-API Entwicklern individuelle API-Keys zuweisen, die erlauben, bestimmte Limits je nach Abonnementmodell festzulegen. Durch Token-basierte Authentifizierung (z. B. OAuth 2.0) kann sichergestellt werden, dass nur autorisierte Nutzer auf sensible Daten zugreifen können. Praxisbeispiele für Rate Limiting und Throttling Rate Limiting und Throttling sind essenzielle Mechanismen in zahlreichen Branchen. Sie gewährleisten eine zuverlässige API-Nutzung und verhindern übermäßige Systembelastungen oder Sicherheitsrisiken. 1. Cloud-Dienste: Fairness und Kostenkontrolle Große Cloud-Anbieter setzen Rate Limits ein, um sicherzustellen, dass alle Kunden fair auf Ressourcen zugreifen können. Beispielsweise kann ein Cloud-Speicher-Dienst die Anzahl von Uploads pro Minute begrenzen, um exzessive Nutzung durch einzelne Kunden zu vermeiden. 2. E-Commerce-Plattformen: Schutz vor Scraping und Missbrauch Online-Marktplätze verwenden Throttling-Mechanismen, um automatisierte Preisabfragen einzuschränken. Ohne solche Limits könnten Wettbewerber oder Bots massenhaft Produktinformationen abrufen, um Preisvergleiche in Echtzeit zu erstellen. Zudem schützt Rate Limiting APIs vor DoS-Angriffen, bei denen massive Mengen an Anfragen absichtlich gestellt werden, um den Service zu stören. 3. Finanzsektor: Betrugsprävention und Sicherheit Banken und Zahlungsdienstleister nutzen Rate Limiting, um betrügerische Transaktionen zu erkennen. Beispielsweise könnte ein Zahlungsanbieter die Anzahl der Geldabhebungen pro Stunde auf eine bestimmte Anzahl beschränken, um verdächtige Aktivitäten zu blockieren. Wenn ein Konto plötzlich hunderte Transaktionen in wenigen Minuten durchführt, wird das Limit erreicht und die API stoppt weitere Anfragen, bis eine manuelle Überprüfung erfolgt. 4. Suchmaschinen: Schutz der Infrastruktur Suchmaschinen begrenzen API-Anfragen, um Serverressourcen optimal zu verteilen. Entwickler, die die Search API nutzen, haben meist ein Tageslimit, z. B. 1.000 Anfragen pro Tag für kostenlose Nutzer. Wer mehr benötigt, muss auf kostenpflichtige Pläne ausweichen. Dies stellt sicher, dass große Unternehmen nicht den gesamten Suchdienst für sich beanspruchen und kleinere Nutzer ebenfalls von der API profitieren können. Fazit Rate Limiting und Throttling sind unverzichtbare Mechanismen zur Steuerung der API-Nutzung. Sie schützen Systeme vor Missbrauch, sichern eine stabile Performance und gewährleisten eine faire Verteilung der Ressourcen. Während Rate Limiting durch feste Begrenzungen den Zugriff reguliert, ermöglicht Throttling eine flexible Lastanpassung, um Überlastungen zu vermeiden. Unternehmen profitieren von diesen Maßnahmen nicht nur durch erhöhte Sicherheit, sondern auch durch eine verbesserte Nutzererfahrung und optimierte Kostenkontrolle. Die Implementierung effektiver API-Nutzungsbegrenzungen ist daher ein essenzieller Bestandteil moderner API-Architekturen. Durch den gezielten Einsatz von Rate Limiting-Strategien und Throttling-Mechanismen können API-Anbieter ihre Services effizient schützen und langfristig skalierbar gestalten.

Die hohe Vernetzung von Mobile-Apps, Cloud-Anwendungen und eingesetzter Software as a Service (SaaS) in der Wirtschaft, Industrie sowie im privaten Umfeld stellen hochwertige Anforderungen an Dienste und Softwaresysteme. Bei der Realisierung von Geschäftsanforderungen werden inzwischen komplexe und leistungsstarke API-Schnittstellen aus der API Economy genutzt. Der zentrale Schlüssel der angebotenen Dienste sind die vielseitigen Funktionen und Informationen die durch die offenen Schnittstellen genutzt werden können. Viele der täglich genutzten Anwendungen basieren auf verschiedenen miteinander verbundenen Diensten. Fällt eine der beteiligten Schnittstellen aus, funktioniert der angebotene Dienst nicht mehr! Um sicher zu stellen, dass die Funktionalität, Zuverlässigkeit, Leistung und Sicherheit der APIs erfüllt werden, sind API-Tests ein Muss. Bei API-Tests werden die APIs (Application Programming Interfaces) direkt und im Rahmen von Integrationstests getestet. Die Tests werden auf Nachrichtenebene durchgeführt. Dabei werden die eingehenden Daten sowie die erwarteten Ergebnisse der Schnittstellen geprüft. Durch die regelmäßige und automatisierte Ausführung der Tests während des API Lifecycle ist sichergestellt, dass die APIs fehlerfrei und stabil ihren Dienst verrichten. Die Qualitätssicherung ist ein wichtiger Bestandteil in der Bereitstellung von hochverfügbaren APIs.

Wer sich mit der Planung, dem Design und der Entwicklung von API-Schnittstellen befasst, wird sich früher oder später mit der API-Definition und einer der hierfür populären Beschreibungssprachen auseinandersetzen müssen. Eine gute API zeichnet sich vor allem durch positive Qualitätsmerkmale aus. Hierzu gehören in erster Linie klare Konsistenz, die möglichst einfache Benutzbarkeit und eine geeignete Abstraktion. Die Bedeutung einer hilfreichen Dokumentation sollte von Anfang an sichergestellt sein und darf niemals unterschätzt werden. Sobald die API auch anderen Entwicklern zur Verfügung gestellt werden soll, muss zwingend eine möglichst ausführliche und umfangreiche API-Definition und Beschreibung dokumentiert werden. Eine leistungsfähige Web-API ist nur dann erfolgreich, wenn seine Struktur gut dargestellt wird. Technische Angaben wie angebotene Endpunkte, verwendete HTTP-Methoden und Parameter und wie Requests auszusehen haben, sind dabei essentiell. All diese Angaben sorgen zum einen für eine gute Anwendbarkeit und unterstützen bei entsprechender Formulierung auch die automatische Codegenerierung. Mit welcher Beschreibungssprache eine API-Definition erstellt wird, bleibt dabei dem Entwickler überlassen. Wir beleuchten hier die gängigsten Sprachen wie Open API, Swagger und RAML. Open-API Unter der Federführung der Linux-Fundation wurde 2015 eine spezielle Arbeitsgruppe mit der Bezeichnung „Open-API Initiative“ gegründet. Parallel dazu wurde auch Swagger von SmartBear - dem Toolhersteller der bekannten und geschätzten SoapUI - übernommen. Beide Schritte führten unter dem Aspekt, weiterhin auch herstellerneutral bleiben zu können, zu der Umbenennung von Swagger zur Open-API Specification (OAS). Inzwischen gehören 26 Mitglieder wie Adobe, SAP, PayPal, eBay, Google, MuleSoft und auch Microsoft dazu. Die konsequente Weiterentwicklung findet auf GitHub statt und eröffnet damit jedem Interessierten die Mitarbeit am Projekt durch Issues oder Pull-Requests. Mitte 2017 wurde dann die Version 3.0 von Open-API verabschiedet und veröffentlicht. Gegenüber der Vorversion 2.0 konnte besonders auf der obersten Ebene der Hosts und der Sicherheit ein klarer strukturierter Aufbau erreicht werden. Ein weiterer großer Fortschritt wurde bei der Unterstützung des JSON-Schema erzielt. Basierend auf den Formaten JSON oder YAML 1.2 können unterschiedlichste Sprachen wie Java, JScript, .Net, Ruby, Scala oder auch Gitlab angewendet werden. Auch in Open-API existieren die Ausgangspunkte Contract-/API-First oder alternativ der Programmcode über Code-First. Eine genaue Beschreibung zu Open-API finden Sie in unserem Praxisartikel Open API Spezifikation. Swagger Das Swagger API-Projekt wurde im Jahr 2011 von Tony Tam ins Leben gerufen. In der inzwischen hoch vernetzten Geschäftswelt ist es immer wichtiger verteilte Anwendungen mit zentralen Servern über API-Schnittstellen kommunizieren zu lassen. Lange Zeit wurden APIs vorzugsweise mit der WSDL (Web-Service Description Language) beschrieben. Der wohl größte Nachteil ist die technische Umsetzung von REST-Schnittstellen. Einer der größten Vorteile von Swagger hingegen ist jedoch das sprachenneutrale und maschinenlesbare Format, welches in der Regel mit JSON oder YAML definiert wird. Zusätzlich bietet es einen leistungsfähigen Erweiterungsmechanismus. Swagger verfügt zudem noch über die IDL (Interface Definition Language) für eine vereinfachte Programmierung von RESTful-Schnittstellen. Darüber hinaus unterstützt Swagger sowohl die Code-First- wie auch die Contract-/API-First- Entwicklung. Mit verschiedenen Tools wie die Kernbibliothek (swagger-core), die Visualisierungsoberfläche (swagger-UI), einen leistungsstarken Editor (swagger-Editor) und den Codegenerator (swagger-Codegen) können sehr komfortabel auch leistungsfähige Schnittstellen entwickelt und getestet werden. Im Rahmen der Beschreibung kann auf Swagger-Tooling zurückgegriffen werden. Hier kann auf dem Quellcode basierend automatisiert eine vollständige Dokumentation erzeugt werden. Eine wesentlich detailliertere Darstellung zu Swagger finden Sie in unserem Artikel Swagger. RAML Was mit Swagger als Quasi-Standard für REST-basierte Anwendungen begonnen hat, wurde mit der Open-API Spezifikation klarer strukturiert und erheblich erweitert. Für die Beschreibung einer REST-API jedoch existiert einerseits kein Standard, auf der anderen Seite wurden SOAP-basierte Web Services bislang immer durch WSDL-Dokumente beschrieben. Mit RAML (RESTful API Modeling Language) ist nun ein weiteres wichtiges Werkzeug für das API First Development verfügbar. Dabei ist die Anforderung für eine einheitliche Beschreibung von REST-API’s nicht wirklich neu. Eine API-Definition hält sich in der Regel immer an folgende auszugsweise Inhalte wie Entry-Point’s, Ressourcenpfade, GET-/PUT-Methoden mit Parametern, Geschäftsobjekten, Typen und Fehlercodes. Die Entwickler von Mulesoft fassten die Notwendigkeit und Vorteile der API-Definition in der modernen Beschreibungssprache RAML zusammen. Dabei profitieren sie im hohen Maße von vielen Vorgängern wie WADL und Swagger. Eine API-Beschreibung erfolgt dabei im Dateiformat YAML. Damit ist es durch seine vereinfachte Notierung zum einen sehr gut lesbar, auf der anderen Seite sind auch komplexe Hierarchien sehr gut darstellbar. Eine begleitende Dokumentation kann auch über mehrere Kapitel angegeben werden. Für einzelne Methoden können Query-Parameter definiert und als sogenannte „Traits“ auch in anderen Methoden eingesetzt werden. Details und Anwendungsmöglichkeiten zu RAML finden Sie in unseren TECH-Artikel RAML. Fazit Die hier aufgeführten Beschreibungssprachen haben eine grundsolide Basis und viele Anhänger. Swagger ist aufgrund der hohen Verbreitung und Toolunterstützung der Quasi-Standard für REST-basierte API-Definitionen. Mit RAML steht eine technisch moderne und leichtgewichtige Beschreibungssprache bereit, die verschiedene Werkzeuge zur API-Modellierung bereitstellt. Die Open API Specification basiert auf Swagger und führt klarere Strukturen und sinnvolle Erweiterungen ein und wird sich langfristig wohl als neuer Standard etablieren.

APIs als Zukunftsmodell in der Logistik Alles begann mit dem Wunsch papierbasierte Vorgänge zu beschleunigen. Vor etwa 40 Jahren starteten die ersten Versuche die Datenübermittlung per Briefpost – was schon mal gut eine Woche dauern konnte – durch die Übermittlung elektronischer Daten zu ersetzen. Vorreiter war damals die Automobilindustrie, die dazu im Jahr 1978 ein eigenes Protokoll entwickelte. Zur Standardisierung des elektronischen Datenaustauschs kam es dann vor rund 30 Jahren durch Edifact, ein Verfahren, das sich auch gleich eines merkwürdigen, neuen Mediums zur Datenübermittlung bediente – Internet genannt. Es begann also mit dem Wunsch nach beschleunigter Übermittlung, doch es ist erheblich mehr daraus geworden. Die rasant gestiegenen Anforderungen sind allerdings nur mittels API-Technik zu befriedigen. Komplexe Datenstrukturen erfordern neue Mittel Mittlerweile geht es nur noch zum Teil um beschleunigte Übermittlungswege. Im Fokus steht heute die Beschleunigung der Kommunikation an sich und mit ihr möglichst kurze Reaktionszeiten. Die Anforderungen an die Unternehmen steigen ständig – das führt zu ständig komplexer werdenden Datenstrukturen. An der Kommunikation und den Geschäftsvorgängen nehmen immer mehr Partner teil: Hersteller, Subunternehmer, Kunden oder Banken sind nur einige davon. Mit anderen Worten: Der Datenaustausch wird von Tag zu Tag anspruchsvoller. Da eine steigende Anzahl von Kommunikationspartnern in die laufenden Übermittlungsprozesse eingebunden werden muss, wachsen entsprechend die Datenmengen an. Gleichzeitig tauchen neue Compliance-Protokolle auf, wobei jede Branche auf ihr eigenes Verfahren setzt. Ständig werden neue Mitglieder in den Club der Kommunikationspartner bei logistischen Prozessen aufgenommen. Da sind beispielsweise cloudbasierte Anwendungen, die ebenfalls beim Datenaustausch mitwirken. Auch mobile Endgeräte mit ihren Apps und nicht zuletzt das Internet der Dinge müssen in den globalen Datenaustausch eingebunden werden. Das die elektronische Datenkommunikation massive Vorteile bei der Effizienz mit sich gebracht hat, ist unbestritten: Steigerung der Ablaufgeschwindigkeit innerhalb der gesamten Lieferkette, hohe Fehlerresistenz, keine Mehrfacheingabe von Daten – das alles ist heute gelebte Wirklichkeit. Die Gefahr droht allerdings genau aus der Richtung, aus der auch die Vorteile stammen. Die unaufhaltsam anwachsende Komplexität der Kommunikationsstruktur führt zu ständig wechselnden Veränderungen bei den Verfahren und Prozessen. Und genau diese Unwägbarkeiten sind es, die die Effektivitätsgewinne des elektronischen Datenaustauschs zunehmend beschneiden und teilweise unwirksam machen. Flexibilität als neues Paradigma Logistische Abläufe erfordern heute vor allem die direkte Einflussnahme auf laufende Prozesse, um flexibel auf aktuelle und zeitkritische Änderungen in den Abläufen reagieren zu können. Hat beispielsweise der Kunde eines Automobilkonzerns versehentlich zehn Fahrzeuge zu wenig bestellt, während seine Bestellung bereits auf dem Weg ist, sind Probleme vorprogrammiert. Die EDI-Standards sehen eine flexible Reaktion auf derartige Sonderfälle nicht vor. In der Regel hängt alles vom Status der Bestellung ab. Stehen die Fahrzeuge noch auf dem Versandparkplatz, ist die Korrektur in der Regel problemlos durchführbar. Schwierig wird es, wenn der Frachter mit den Autos bereits auf hoher See ist. Wie die Nachlieferung erfolgen soll und wie es mit den zusätzlichen Versandkosten aussieht, steht zunächst in den Sternen. APIs als Effizienz-Booster Problemlagen wie diese lassen sich mit herkömmlichen Mitteln nicht automatisieren – weder durch EDI-Standards noch auf eine andere Art und Weise. Hier ist die Anwendung von APIs gefragt, die den exakt definierten Zugriff auf interne Unternehmenssysteme steuern. Im erwähnten Beispiel könnte der Kunde die Daten des Lieferanten in sein System integrieren und auf der Basis der Echtzeitinformationen einen automatisierten Prozess für Nachbestellungen festlegen. Die große Stärke von APIs ist ihre Fähigkeit Sonderfälle zu berücksichtigen. Das ist sowohl im Bereich B2C als auch bei B2B von großer Bedeutung. Die Anwendungsmöglichkeiten reichen von der Sendungsverfolgung für Privatkunden bis zu Trackingdaten oder Echtzeitinformationen innerhalb des Bestellsystems bei Unternehmenskunden. APIs stoßen in der Logistik eine neue Tür auf, so wie damals der Wechsel vom Papier zu elektronischen Daten. Die Möglichkeiten, die sich daraus ergeben, stehen noch ganz am Anfang. APIs haben ihr Potential erst ansatzweise bewiesen – die kleine Spitze eines sehr großen Eisbergs.

API-Economy: Mit API-Produkten zu neuen Einnahmequellen Der phänomenale Siegeszug von APIs in den letzten Jahren hat Entwicklern völlig neue Perspektiven eröffnet. Immer mehr Unternehmen erkennen die immensen wirtschaftlichen und organisatorischen Vorteile, die aus einer auf APIs basierenden Softwarearchitektur erwachsen. Der nächste Schritt war abzusehen: Aus APIs wurden API-Produkte, maßgeschneidert auf die individuellen Bedürfnisse der Kunden. Für die Unternehmen bedeutet das die Konzentration auf das Wesentliche. Für Entwickler von API-Produkten bedeutet es die Entstehung eines neuen, lukrativen Marktes. API-Produkte sind digitale Kompetenz API-Economy, also der Wirtschaftsbereich, der sich mit der Entwicklung und dem Vertrieb von API-Produkten befasst, basiert auf einer einfachen, aber bestechenden Erkenntnis: Nicht jeder kann alles wissen. Sich zusätzliches Können anzueignen, das für das eigene Geschäftsmodell gebraucht wird, erfordert Zeit, Geld und Ressourcen. Da bei der Entwicklung neuer Geschäftsfelder in der Regel eine Reihe neuer Kompetenzen gefragt sind, vervielfacht sich der Aufwand mit jeder zusätzlichen Kompetenz – ein Aufwand, der sich in vielen Fällen nicht rechnet. Der alternative Weg wäre, die fehlende Kompetenz einfach zuzukaufen. Das ist der Augenblick, in dem APIs ins Spiel kommen. Von der API zum API-Produkt Vereinfacht ausgedrückt sind APIs Schnittstellen, über die Software auf spezielle Funktionalitäten anderer Applikationen zugreifen kann. Mit anderen Worten: Die Software nutzt die Kompetenz, die ihr über die API zur Verfügung gestellt wurde, ohne über einen eigenen Programmcode zu verfügen, der diese Kompetenz beschreibt. Das Problem dabei: In der Regel stellt die API nur eine spezielle Kompetenz zur Verfügung. Zur Bewältigung komplexer Aufgaben in Unternehmen sind aber in der Regel Kombinationen unterschiedlicher Kompetenzen erforderlich, die aufeinander abgestimmt und exakt koordiniert ablaufen müssen. Diese Aufgabe erfüllen API-Produkte, also die Kombination unterschiedlicher APIs für verschiedene Teilbereiche des Tasks. Dabei müssen die einzelnen APIs nicht nur ihre speziellen Aufgaben erfüllen, sondern auch optimal mit den anderen APIs kommunizieren, um im Interesse des anvisierten Ziels reibungslos zu interagieren. Entwickler von API-Produkten stehen zwei Varianten zur Verfügung, um ein für den Kunden maßgeschneidertes API-Produkt zu kreieren: Entweder stammen alle im Produkt enthaltenen APIs aus eigener Entwicklung oder das API-Produkt besteht aus speziell aufeinander abgestimmten, bereits existierenden APIs. In vielen Fällen sind auch Kombinationen möglich: Kompetenzen, für die bereits Dritt-APIs existieren, werden durch diese bedient. Für alle weiteren ist die Entwicklung neuer APIs erforderlich. Das Produkt besteht dann aus existierenden und neuen APIs, die optimal aneinander angeglichen werden. Speziellen Funktionen sind keine Grenzen gesetzt Insbesondere durch die Kombination aus APIs von Drittanbietern und selbst programmierten APIs eröffnen sich Entwicklern ungeahnte Möglichkeiten bei der Gestaltung individueller Applikationen für den jeweiligen Kunden. Dabei sind Lösungen denkbar, die API-Produkte für die interne Eigennutzung im Unternehmen zum Ziel haben oder solche, die als Bestandteil des Geschäftsmodells für die Nutzung durch die Unternehmenskunden ausgelegt sind. So lassen sich differenzierte Soft Limits implementieren, beispielsweise das Throttling, um die Zugriffszahlen innerhalb eines bestimmten Zeitraums zu beschränken. Solche und andere Funktionalitäten können exakt nach den individuellen Vorgaben des Kunden in das API-Produkt eingebracht werden. Bei der Preisgestaltung stehen dem Entwickler alle Möglichkeiten offen – von Preis pro Abfrage über Staffelpreise für unterschiedliche Ausbaustufen bis hin zu Flat-Lösungen. Darüber hinaus sind Preismodelle denkbar, die auf speziellen Anwendungsszenarios basieren. Fazit API-Produkte sind die Antwort auf das Problem von Unternehmen, zusätzliche Kompetenzen mit vertretbarem Aufwand zu generieren. Für Entwickler bedeuten API-Produkte einen quasi unerschöpflichen neuen Markt, auf dem sie Unternehmen über maßgeschneiderte Lösungen mit genau den Kompetenzen versorgen, die ihnen fehlen.

Die Ausrichtung an Kundenbedürfnisse ist für die Bankenwelt von zunehmendem Interesse. Die Geldinstitute sind sich einig, dass in den APIs, die Abkürzung für Application Programming Interface, enormes Potenzial liegt. Die APIs erlauben die Nutzung sowie Auswertung von Daten und Funktionen auf Bankkonten. Die Öffnung der Core-Banking Funktionen für Drittanbieter eröffnet neue Möglichkeiten. Weshalb setzen Finanzdienstleister vermehrt auf Open Banking? Die Finanzwelt steht einer neuen Ära gegenüber, deren Ausmaß sich heute noch nicht realistisch abschätzen lässt. Ein Richtungswechsel, der das traditionelle Selbstverständnis der Banken angreift. Weg von der starren Fessel des Beharrens, hin zu neuer Flexibilität, die sich international agierende Marktbetreiber und Markteilnehmer erhoffen. Tatsächlich stehen die Wünsche und Anforderungen der Kunden, deren Konsumbedürfnisse, im Fokus der Entwicklungen. Eine Sichtweise, mit der sich Finanzdienstleister neu und innovativ positionieren können, die definitiv eine neue Herausforderung darstellt. Der Kompass der Europäischen Union zeigt zweifelsfrei in Richtung Wettbewerbsverschärfung. Mit der Payment Services Directive II (PSD II) steht einer Öffnung der Bankeninfrastruktur nichts mehr im Wege und es wird damit die Freiwilligkeit zugunsten der verbindlichen Verpflichtung abgelöst. Welche Vorteile hat Open Banking für die Märkte und Anbieter? Ein Anbieter der mittels API den Zahlungsprozess einleitet und teilweise steuert, profitiert in erster Linie an der Gewinnung von Informationen. Wissen über den Kunden, welches über die Notwendigkeit des reinen Verkaufs- oder Serviceprozesses hinausgeht. Damit wird ein Regelwerk entstehen, das mehr ist, als die reine Verwaltung der Kundendaten. Wer künftig die Hoheit über die Informationen hat, gestaltet und steuert den Markt. Die neue Währung an den Finanzplätzen ist Wissen um das Kundenverhalten. Es steht außer Frage, dass nichts wertvoller ist als die Information, darüber, wer zu welchem Zeitpunkt welches Produkt über welches Medium gekauft hat, oder es statistisch gesehen gerne kaufen würde. Was bedeutet Open Banking für den Kunden? Mit Open Banking geben die Banken Drittanbietern die Möglichkeit, auf Kundendaten zuzugreifen und Transaktionen auf Bankkonten auszulösen. Dem Kunden wiederum stehen eine Anzahl von Dienstleistungen unter einer Oberfläche, zur Verfügung. Diese neue Art der Kundenfreundlichkeit, hat den Vorteil, dass nun alle Banktransaktionen flexibel und mit mehr Komfort abzuwickeln sind. Innerhalb einer Anwendung sind mehrere Konten zu managen. Dafür werden von Drittanbietern für den Zahlungs- und Finanzverkehr (FinTech-Unternehmen), Apps angeboten, die mittels API auf die bestehenden Bankverbindungen zugreifen können. Durch diese API’s ist umfassende Verfügbarkeit der Bankdaten für alle anderen Anbieter möglich. Für Kunden wird Banking und Management externer Finanzdaten und Dienstleistungen einfacher, vielseitiger, innovativer. Welche Möglichkeiten haben Kunden mit Open Banking API’s? Eine App, die von einem Dritten (FinTech) angeboten wird, kann von der Bank, dem App-Anbieter und dem Kunden genutzt werden. Künftig werden Kunden, in der höchsten Ausbaustufe, auf einer einzigen Plattform, ihre gesamten Finanztransaktionen erledigen und Zusatzservices anbinden können. Die Konfiguration solcher Frontends nimmt der Kunde weitgehend selbst vor. Für die Anbieter steht vordergründig die Usability (Benutzerfreundlichkeit) im Fokus, im Hintergrund bestimmt die komplexe Vernetzung aller Daten den Entwicklungsprozess, um die verschiedenen Services bereitzustellen. Wie kann künftig ein User Interface für den Kunden aufgebaut sein? Abhängig von den Bankverbindungen und zusätzlichen Services ist der Aufbau der Plattform unter dem Schlagwort Personal Finance Management (PFM) so denkbar: Multi-Banking, sämtliche Bankkonten auf einen Blick übergreifende Funktionen und Transaktionen werden möglich Kreditkarten sind eingebunden Erledigung des gesamten Zahlungsverkehrs über Konten und Kreditkarten Integration zusätzlicher Zahlungsdienstleister Einbindung von Investitions- und Anlageplattformen Anbindung von Shop-Plattformen (Amazon, Shopify, etc.) Verwaltung Bitcoin-Wallet und anderer Kryptowährungen Durch die intelligente Vernetzung durch APIs sind alle Dienste sowie Services miteinander verbunden und stehen im direkten Austausch. Banken wandeln sich zum Marktgestalter und flexiblem Dienstleister, erschließen neue und innovative Geschäftsfelder.