Gute APIs sind ein wesentlicher Bestandteil von gutem Code. Sie sind die Zäune, die Entwickler ziehen, wenn sie Projekte aufteilen, Bibliotheken erstellen und ihre Arbeit mit anderen teilen. Gute APIs sind jedoch in zunehmendem Maße auch die Grundlage für gute Geschäfte. Schließlich sie sind nicht nur ein Gateway zu Daten und Entscheidungsintelligenz, sondern ein Produkt, das dafür konzipiert wurde, monetarisiert zu werden: APIs bieten Möglichkeiten, Nutzer für deren Verwendung zur Kasse zu bitten.

Leider ist es nicht ganz einfach, diese APIs zu erstellen, um dann den Rubel rollen zu lassen. Einmal eingerichtet, kann eine API Anfragen von jedem Gerät im Internet entgegennehmen. Legitime Nutzer klopfen dann genauso an die Unternehmenstür wie potenziell böswillige. Im schlimmsten Fall nimmt dann das Chaos seinen Lauf.

14 Fallstricke für API-Strategien

Aufgabe ist es, die Programmierschnittstellen so zu gestalten, dass sie für die richtigen Entwickler einfach zu bedienen und für die falschen Entwickler nicht nutzbar sind. Wir haben 14 häufige Herausforderungen zusammengetragen, die, wenn sie nicht gelöst werden, Ihrer API-Strategie empfindlichen Schaden zufügen können.

1. Exfiltration nicht einkalkulieren

Viele Cloud-Anbieter stellen mehr Posten in Rechnung, als ihre Kunden sehen. Dass Compute-Einheiten Geld kosten, ist offensichtlich. Weniger klar ist manchem User, dass ein hoher Preis auch darin bestehen kann, für Datenexfiltration zu zahlen, denn letztendlich ist das die Hauptaufgabe einer API: Daten an die Nutzer zu exfiltrieren.

Unternehmen sollten darauf achten, diese Kosten bei der Preisgestaltung für Ihre API zu berücksichtigen - und auch bei der Modellierung ihrer Architektur.

2. Für das Datenformat kann eine "Steuer" anfallen

Einige Datenformate, etwa XML, sind nicht so effizient wie andere. Das kann sich auf die Größe der Datenpakete auswirken, die Ihre API zurückgibt. Eine meiner Freundinnen prahlt immer noch gerne damit, wie sie die Datenrechnungen für ihr Unternehmen um mehr als 40 Prozent senken konnte, nur weil sie die zusätzlichen Tags und den ganzen Ballast im Datenformat beseitigt hat. Die Datenkosten für ein Unternehmen lassen sich reduzieren, wenn Sie das Datenformat so schlank wie möglich halten und die Daten auf die notwendigen Bits beschränken, damit Ihre Bandbreitenrechnung überschaubar bleibt.

3. Zu viele Features

Manchmal möchten Entwickler andere mit einer Vielzahl zusätzlicher Funktionen erfreuen. In den meisten Fällen verursacht das keine Probleme, selbst wenn diese nicht genutzt werden. Mitunter entstehen so aber unbemerkt Sicherheitslücken.

Der Programmierer, der die Log4J-Bibliothek um die Möglichkeit erweitert hat, beliebigen Code auszuführen, hatte sicher nicht vor, eine der schlimmsten Sicherheitslücken aller Zeiten zu schaffen. Weil er vergessen hat, wie mächtig diese selten genutzte Funktion ist, wurde sie genau das. Oft ist es sinnvoll, sich auf das Wichtigste zu beschränken. Dabei mag nicht immer ein tolles Produkt entstehen, aber wenn es darum geht, eine sichere API zu entwickeln, ist weniger oft mehr.

4. Pre-Filter vergessen

Die meisten APIs verrichten selbst nicht viel Arbeit: Sie nehmen Input entgegen und leiten diesen an irgendeinen anderen Code weiter. Einer der besten Dienste, die eine API dabei leisten kann, ist das Pre-Filtering. Es gewährleistet, dass der Input exakt den Erwartungen entspricht. Einige der schlimmsten Sicherheitslücken sind auf Angriffe zurückzuführen, die diesbezügliche Fehler in einer API missbrauchten, um so einen Buffer-Overflow- oder einen SQL-Injection-Angriff zu erzeugen.

5. Unzulängliche Tests

Viele Entwickler nutzen ein paar grundlegende Test-URLs. Wenn das richtige Paket von der API zurückkommt, gehen sie davon aus, dass alles reibungslos läuft. In Wirklichkeit werden die Testergebnisse aber oft zwischengespeichert und diese Test-URLs nutzen vielleicht nur die oberste Ebene. Eine gute Test-Suite stellt sicher, dass jeder Teil einer API geprüft wird - insbesondere die Verbindung zur Datenbank und allen sekundären APIs oder Services.

6. CORS-Fehlkonfiguration

Probleme beim Cross-Origin Resource Sharing (CORS) können auftreten, wenn die Antwort einer API direkt mit einem anderen Inhalt in einem Browser vermischt wird. Das kann vor allem für API-Benutzer eine Herausforderung sein, die es besonders eilig haben. Manchmal besteht die Lösung im Hinzufügen des Tags Access-Control-Allow-Origin zu den Headern. Manchmal ist es besser, einen vollständigen Proxy in den Stack zu integrieren.

7. Die falsche Autorisierung wählen

Das richtige Maß an Autorisierung für eine API festzulegen, ist eine Kunst für sich. Einige Daten sind nicht allzu sensibel. Die einzige Aufgabe der API besteht dann beispielsweise darin, Nutzer zu tracken, um bestimmte Rechnungen zu verfolgen. Für solche einfacheren Fälle genügt im Regelfall ein unveränderlicher Random-Key.

Andere APIs schützen hingegen persönliche Daten, die sehr sensibel sein können. In diesen Fällen sind sicherere Protokolle wie OAuth 2.0, OpenID oder JWT die bessere Wahl. Es gibt bereits gute Bibliotheken, so dass für die Optimierung der Sicherheit nicht viel neuer Code geschrieben werden muss.

8. Anomalien in Log-Files ignorieren

Wenn die Software läuft und es keine panischen Anrufe von Kunden gibt, neigen Programmierer dazu sich zurückzulehnen. Logfiles für APIs können jedoch helfen Gefahren zu erkennen, bevor sie auftreten. Gibt es spezifische Parameter, die der Software Probleme bereiten? Erhöht sich die Last an bestimmten Tagen, zu bestimmten Zeiten oder wenn ein Kunde auftaucht?

Wenn Sie nur ein paar Minuten damit verbringen, die Logfiles auf schlechte Antwortzeiten hin zu überprüfen, werden Sie etwa feststellen, ob Ihre Hardware unterdimensioniert oder Ihre Software fehlerhaft ist. Gelingt es, diese Probleme frühzeitig beheben, können Entwickler ernstzunehmende Probleme in der Zukunft verhindern.

9. Falsches Caching

APIs verkürzen Antwortzeiten und reduzieren den Compute-Bedarf, indem sie die Ergebnisse häufig gestellter Fragen zwischenspeichern. Wenn dieses Caching gut funktioniert, erhält jeder schnell die Antworten, die für seine Zwecke noch aktuell genug sind. Wird das Zwischenspeichern aber zu aggressiv betrieben, müssen die Benutzer veraltete Antworten hinnehmen und können nicht mehr feststellen, wann sie generiert wurden. Mit wenig oder gar keinem Caching zu arbeiten, löst dieses Problem, muss aber mit höherem Rechenaufwand und mehr Komplexität bezahlt werden. Das optimale Gleichgewicht zu finden, ist eine Herausforderung.

10. Ein eigenes Framework nutzen

Die API-Entwicklung ist heute so fortgeschritten, dass Entwickler guten gewissens auf Frameworks wie Swagger, OpenAPI oder eine der kommerziellen Versionen der Cloud-Anbieter zurückgreifen können. Sie schreiben dann nur ein paar Zeilen, um die Parameter festzulegen - das Framework übernimmt den Rest. Zudem verfügen diese Frameworks über gute Filter, um Missbrauch zu verhindern und bieten moderne Messverfahren, um die Nutzung zu tracken. Etwas Eigenes zu erstellen, ist vor diesem Hintergrund zunehmend überflüssig.

11. Kostenlose Software ignorieren

Wenn Ihre API für ein größeres Publikum von Entwicklern aus einer Vielzahl von Unternehmen gedacht ist, kann die Nutzung frei verfügbarer Software helfen, neue Nutzer zu gewinnen. Immer dann, wenn Programmierer erst ihre Vorgesetzten um Erlaubnis und Budget bitten müssen, wird es für sie schwieriger zu experimentieren und zu demonstrieren, was Ihre API bieten kann. Andererseits besteht das Risiko, dass der Anteil kostenloser Elemente so großzügig gestaltet ist, dass Entwickler die API nutzen, ohne dafür zu zahlen.

Den richtigen Mittelweg zu finden, ist eine Herausforderung. Einige APIs lassen sich leicht zwischenspeichern, weil sich die zugrundeliegenden Daten nie ändern. Das bedeutet, dass kostenlose Nutzer den Zugriff strecken können. Seien Sie deshalb geizig mit Daten, die sich leicht über lange Zeiträume zwischenspeichern lassen. Seien Sie jedoch großzügiger, wenn der Haupt-Output schnell veraltet oder möglicherweise nie zwischengespeichert wird.

12. Falsche Preisgestaltung einer API

Die größte Herausforderung für alle, die einen API-Zugang monetarisieren wollen, ist die Bepreisung. Ist der Preis zu niedrig angesetzt, geraten die Umsatzziele in Gefahr. Ist er zu hoch, werden sich potenzielle Nutzer zurückhalten. Leider gibt es keine allgemeingültige Lösung für dieses Problem. Manche Unternehmen versuchen es mit dem Festlegen von Premium-Stufen, um Einnahmen vor allem mit Großkunden zu erzielen. Andere setzen einen hohen Grundpreis fest und bieten dann großzügige Rabatte.

13. Serverless-Vorteile ungenutzt lassen

Tools wie Cloudflare Workers oder Lambda von AWS sind nicht für jede API geeignet, stellen aber in vielen Fällen ideale Lösungen dar. Sie bieten einen einfachen, weitgehend verbrauchsabhängigen Preispunkt. Auf dieser Basis fällt es leichter, ein funktionierendes Geschäftsmodell zu entwickeln.

Wenn das Cloud-Unternehmen für jeden Funktionsaufruf den Betrag X berechnet und jeder API-Aufruf zu als Funktionsaufruf gilt, können Sie sich ausrechnen, welchen Betrag sie für jede API berechnen müssen, um die Kosten für die Infrastruktur zu decken. Alle APIs weisen eine unterschiedliche Kostenstruktur auf - einige können richtig ins Geld gehen. Serverless-Modelle erleichtern es jedoch die variablen Kosten für den Betrieb einer Schnittstelle zu berechnen.

14. Humorlose Fehlermeldungen

Jede API bietet die Gelegenheit, etwas Humor ins Spiel zu bringen. Nutzen Sie das für Eastereggs. Möglicherweise steigern Sie so den Bekanntheitsgrad ihrer Produkte - ähnlich wie die Sprachassistenten Siri und Alexa, die auf bestimmte Fragen lustige Antworten geben. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CIO.com.