Wie wird meine API public?

Warum APIs?

APIs (Application Programming Interfaces) dienen bereits seit Jahrzehnten als Schnittstellen, um Anwendungen miteinander kommunizieren zu lassen. Mit dem Einsatz von RESTful APIs hat sich ihre Rolle in den letzten Jahren jedoch drastisch verändert.

Immer mehr Unternehmen entwickeln eigene APIs und ermöglichen es sogenannten Consumern (Nutzer der APIs) innerhalb sowie außerhalb des Unternehmens auf interne Dienstleistungen und Produkte zuzugreifen. Damit verstärken die Firmen nicht nur die Digitalisierung ihrer Unternehmensdaten. Sie ermöglichen es Consumern neue Anwendungen damit zu konstruieren und erschließen dadurch komplett neue Geschäftsfelder.

Private oder Public

Intern verwendete – sogenannte private APIs – sind nur Entwicklern innerhalb einer Organisation zugänglich. Meistens werden diese APIs benutzt, um interne Teamprozesse zu verbinden, so dass Arbeit weniger isoliert verrichtet wird und die Zusammenarbeit somit optimiert werden kann.

Öffentliche APIs – sogenannte public APIs – hingegen bieten externen Entwicklern eine Möglichkeit, bequem auf die internen Unternehmensdaten zuzugreifen und diese Informationen dann für eigene Anwendungsfälle zu verwenden oder mit den Daten aus anderen public APIs zu verbinden.

Die Ansprüche an eine öffentliche API sind dabei deutlich höher als die an eine interne API. Qualitätsmängel, die bei internen APIs vielleicht unschön und verschmerzbar sind, werden sich bei öffentlichen APIs negativer auswirken, da eine deutlich größere Anzahl von Entwicklern die API benutzen wird.

Die Qualität der API hat somit auch einen höheren Einfluss auf die Reputation des Providers.

Photy by Luke Chesser on Unsplash

Die Entwicklung und Bereitstellung von public APIs gehört zu einer unserer Kernkompetenzen. Wir unterstützen unsere Kunden vom Design bis hin zum Betrieb von public APIs. Dabei haben wir für uns standardisierte Konzepte entwickelt, die uns helfen, viele Probleme schon im Vorhinein zu lösen.

Welche wichtigen Erfolgsfaktoren sind beim Entwurf einer public API zu berücksichtigen?

Die fertige Schnittstelle soll in erster Linie den Bedürfnissen ihrer Benutzer entsprechen. Von Entwicklern nicht akzeptierte APIs verursachen hohe Kosten, während gleichzeitig die Geschäftsziele verfehlt werden. Ist eine Schnittstelle erst einmal entworfen und fertig entwickelt, gestaltet sich die Fehlerkorrektur schwierig und zeitaufwendig. Unter Umständen muss dann wieder von vorn angefangen werden: eine neue API entwerfen, sie über eine Verbindung zu den Daten liefernden Applikationen implementieren und sie zum Schluss erneut veröffentlichen. Am gravierendsten ist jedoch, dass sie alle bestehenden Consumer auf die neue Version umstellen müssen.

Die API muss einfach zu verstehen und zu benutzen sein. Entwickler sollten die Funktionalität der API abschätzen und sie innerhalb von wenigen Minuten einsetzen können.

Um dies zu gewährleisten, sind bei der Entwicklung von öffentlichen APIs einige Grundsätze zu beachten.

Im Vordergrund muss das Design stehen. Ein gutes API-Konzept erleichtert Anwendungsentwicklern den Überblick über den Verwendungszweck und die Funktionalität der Schnittstelle.

Dies beinhaltet neben einer benutzerfreundlichen Dokumentation auch, dass die Versionierung nachvollziehbar geregelt ist.

Um all diese Anforderungen adäquat umsetzen zu können, empfiehlt es sich unternehmensweite, standardisierte Regelungen für öffentliche APIs aufzustellen. Dabei kann der Einsatz einer API-Management-Plattform Erleichterung schaffen. Häufig verwendete Plattformen sind unter anderem apigee, 3scale, IBM API Management, akana oder Kong. Die Unterschiede der aufgeführten API Management Tools liegen vor allem in der Preisgestaltung und in einigen Funktionalitäten, auf die hier nicht näher eingegangen werden soll.

Generelle Funktionen einer API Management Plattform sind:

• API Portal: Bietet Zugang, Kontrolle, Prüfung und Dokumentation

• API Lifecycle Manager: Kontrolliert den Weg vom Entwurf bis zum Abschluss

• API Policy Manager: Kontrolliert die Richtlinien, die dazu beitragen, die Sicherheit der API zu gewährleisten

• API Analytics: Enthüllt Metriken, die für fundierte Geschäftsentscheidungen verwendet werden können

• API Gateway: Verbindet den API Provider und Consumer

In der pentacor hat sich für die Konzeption von public APIs ein Template-Ansatz bewährt, der bereits in einem frühen Stadium die Anforderungsanalyse unterstützt. Dieser Fragenkatalog klärt unter anderem folgende wichtige Details:

• Name des API-Produktes: Als API Provider ist es möglich, mehrere APIs zu einem Produkt zusammenzufassen. Zusätzlich ist es möglich, den Zugriff auf die API-Ressourcen im API-Produkt zu steuern. Zum Beispiel ist es möglich, unterschiedliche Ressourcen bereitzustellen, auf die abhängig vom Bezahlmodell zugegriffen werden kann. Es existiert dann ein Produkt, bei dem jede Anfrage abgerechnet wird, sowie ein zweites Produkt, welches über eine Flatrate abgerechnet wird und unbeschränkten Zugriff erlaubt. API-Produkte sind der zentrale Mechanismus für Autorisierung und Zugriffskontrolle zu den APIs. Jeder Consumer muss als erstes seine Applikation registrieren, um auf das API-Produkt zugreifen zu können. Nach erfolgreicher Registrierung erhält man einen API Key, mit dem auf das Produkt zugegriffen werden kann.

• Autorisierung: Wie bereits erwähnt, spielt die Zugriffskontrolle auf die API eine wichtige Rolle, damit nur berechtigte Zugriffe auf die APIs erfolgen. Zusätzlich zum bereits genannten API Key kann man den Zugriff auch über OAuth 2.0 schützen.

• Zum Schutz der Applikation vor Überlastung gibt es die Möglichkeit, einen Quota Check oder Spike Arrest zu konfigurieren

• Quota Check: Eine Quota Policy steuert die Anzahl der Anfragen, die ein API Proxy über einen gewissen Zeitraum, wie z.B. Minute, Stunde, Woche oder Monat, zulässt. Die Quota kann entweder global für alle Applikationen, die auf den Proxy zugreifen, oder nur für ein bestimmtes Produkt, eine bestimmte Applikation oder einen bestimmten Consumer konfiguriert werden.

• Spike Arrest: Die Spike Arrest Policy schützt gegen Lastspitzen. Dabei wird die Anzahl der Anfragen, die vom API Proxy an das Backend weitergeleitet werden, gedrosselt und Performance-Einbrüche und Ausfälle der Applikation werden somit verhindert.

• Backend Call Security spielt eine ebenso große Rolle. In unseren Projekten wird sehr oft SSL/TLS in der Kommunikation zwischen API-Management-Plattform und an der Applikation eingesetzt.

• Monetarisierung: Wie schon beim API-Produkt erwähnt, ist es möglich, einzelne Produkte kostenpflichtig anzubieten. Jeder Consumer sendet mit jeder Anfrage seinen API Key mit und ist damit eindeutig identifizierbar. Dies ermöglicht ein Monitoring, wer welche API wie oft nutzt. Diese Daten können sowohl für Analysen und Reports als auch zur Monetarisierung herangezogen werden. In unseren Projekten hat es sich bewährt, auch kostenlose Zugriffe auf die API anzubieten. Diese erlauben im Tryout-Produkt [1] Zugriff auf Dummy-Daten oder in einem Trial-Produkt [2] eine begrenzte Anzahl Zugriffe auf reale Daten. Mit diesen Produkten ermöglicht man dem Entwickler die API zu testen und man verkauft nicht die „API im Sack“.

Darüberhinaus ist eine gut verständliche Dokumentation der API nicht zu vernachlässigen. Natürlich kann man viele technische Details direkt aus der OpenAPI-Spezifikation herauslesen. Zusätzlich sollte man jedoch eine sogenannte Benutzungsdokumentation bereitstellen, welche eine ausführliche Beschreibung zu den einzelnen angebotenen Endpunkten der API enthält, die durch Beispiele ergänzt wird.

Zum Abschluss ist noch zu erwähnen, dass für das Installieren der API-Proxy-Konfigurationen ein automatisierter Prozess verwendet werden sollte.

Zusammenfassung

Um eine public API bereitzustellen, muss man viele Aspekte beachten. Um allerdings schon im Vorfeld die häufigsten Fehler und Problemen zu umgehen, hilft es sich bei der Konzeption und Entwicklung an standardisierte Vorlagen zu halten. Wer sich selbst einmal näher mit public APIs beschäftigen möchte, kann zum Beispiel unter https://docs.apigee.com/api-platform/get-started/get-started einen eigenen API Proxy in der sogenannten Edge UI von apigee testweise aufsetzen. Dabei kann man sich mit den hier im Blog genannten Aspekten der public APIs vertraut machen.

[1]  Ein Tryout-Produkt besitzt den Funktionsumfang der realen API. Es wird jedoch nur auf statische Dummy-Daten zugegriffen.

[2] Ein Trial-Produkt ist identisch zur realen API. Dem Consumer werden darüber eine gewisse Anzahl von Zugriffen auf die echten Daten ermöglicht.