Wer die Kosten der individuellen API-Entwicklung an der Zahl der Endpunkte festmacht, liegt daneben, meist um den Faktor drei. Endpunkte sind der billigste Teil. Ein Dutzend davon, die Daten lesen und schreiben, die Sie ohnehin schon halten, sind für eine kompetente Backend-Entwicklerin zwei Wochen Arbeit.

Geld kostet alles, was aus diesen Endpunkten etwas macht, worauf ein anderes Unternehmen sein Geschäft aufbaut: eine Authentifizierung, die eine Sicherheitsprüfung übersteht, eine Versionierung, die Ihnen erlaubt, Ihre Meinung später zu ändern, eine Dokumentation, die gut genug ist, dass niemand eine E-Mail schreibt, und der Betriebsapparat, der Ihnen verrät, welcher Kunde gerade einen schlechten Vormittag hat. Zwischen „wir haben eine API" und „wir haben eine API, auf die sich andere verlassen" liegt das Budget.

Preisbänder auf einen Blick: Eine interne API, die nur von Ihren eigenen Anwendungen genutzt wird, kostet typischerweise 10.000 bis 30.000 Pfund. Eine Partner-API, die eine Handvoll benannter Integratoren nutzt, liegt in der Regel bei 40.000 bis 100.000 Pfund. Eine öffentliche API, die Teil Ihres Produkts ist, mit Selbstbedienungs-Onboarding und veröffentlichtem Vertrag, beginnt bei rund 100.000 Pfund und kostet nach dem Start weiter.

Was Sie tatsächlich kaufen

Eine API ist ein Produkt mit Nutzern, und sie braucht, was Produkte brauchen. Diese Liste gegen ein Angebot zu halten, ist der schnellste Weg zu sehen, was darin fehlt.

Entwurf und Vertrag. Jemand muss über Ressourcenmodell, Namenskonventionen, Fehlerformat, Paginierung und Filtersyntax entscheiden und das als Spezifikation aufschreiben, bevor die Umsetzung beginnt. Wer das überspringt, bekommt eine API, in der drei Endpunkte dasselbe Problem auf drei verschiedene Arten lösen, und den Konsumenten fällt das sofort auf.

Authentifizierung und Autorisierung. API-Schlüssel sind einfach und für den internen Gebrauch angemessen. Partner-APIs und öffentliche APIs brauchen meist einen richtigen tokenbasierten Ablauf mit Geltungsbereichen, Ablaufzeit und Rotation, dazu Berechtigungen je Konsument, die bei jeder Anfrage geprüft und nicht aus dem Schlüssel abgeleitet werden.

Ratenbegrenzung und Kontingente. Limits je Konsument schützen Ihre Infrastruktur vor dem entlaufenen Stapeljob eines einzelnen Integrators. Sie müssen zugleich über Antwort-Header mitgeteilt werden, damit sich gutwillige Clients zurücknehmen können, und sie brauchen einen Ausnahmeweg für den Kunden, der berechtigterweise mehr benötigt.

Woran Konsumenten Sie messen

Dokumentation. Eine generierte Referenz ist die Mindestanforderung. Was Konsumenten wirklich brauchen, ist ein Einstiegsleitfaden, eine Anleitung zur Authentifizierung, ausgearbeitete Beispiele in ein paar Sprachen und ein Änderungsprotokoll. Gute Dokumentation ist ein echtes Arbeitsergebnis, das in Wochen gemessen wird, und sie entscheidet darüber, ob sich eine API von selbst verbreitet oder auf Dauer Supportanfragen erzeugt.

Eine Sandbox. Partner werden nicht gegen die Produktion testen, und Sie sollten es auch nicht wollen. Eine Testumgebung mit realistischen Daten, zurücksetzbarem Zustand und denselben Validierungsregeln gehört zu den am häufigsten weggelassenen Posten in einem API-Angebot und zu den am häufigsten geforderten Funktionen nach dem Start.

Beobachtbarkeit. Sie müssen Anfragemengen, Fehlerquoten und Latenz je Konsument sehen können, denn „die API ist langsam" ist nur dann handhabbar, wenn Sie sagen können, wessen Anfragen langsam sind. Korrelationskennungen, mit denen sich der fehlschlagende Aufruf eines Kunden durch Ihre Protokolle verfolgen lässt, zahlen sich schon im ersten Supportmonat aus.

Tests. Über Unit-Tests hinaus braucht eine API Vertragstests, die den Build scheitern lassen, wenn sich eine Antwortstruktur unbeabsichtigt ändert. Dieses Sicherheitsnetz ist der Grund, warum Sie weiterentwickeln können, ohne die Integratoren zu brechen, die Ihnen vertraut haben.

Die drei Stufen und warum sie sich so stark unterscheiden

Dieselben Endpunkte kosten sehr unterschiedlich viel, je nachdem, wer sie nutzt, denn das Publikum bestimmt die Toleranz für Unvollkommenheit.

Interne APIs bedienen Ihre eigenen Anwendungen. Ihr Team kontrolliert beide Enden, brechende Änderungen lassen sich abstimmen, die Dokumentation darf knapp bleiben, und die Authentifizierung kann sich auf Netzgrenzen stützen. Typische Kosten: 10.000 bis 30.000 Pfund für einen sauber gebauten Dienst mit vernünftigen Tests und Monitoring.

Partner-APIs bedienen eine bekannte Menge externer Organisationen. Jetzt brauchen Sie echte Authentifizierung, aussagekräftige Fehlermeldungen, eine Sandbox, geschriebene Dokumentation und eine Versionierungsrichtlinie, denn Sie können nicht an einem Dienstagnachmittag eine brechende Änderung ausrollen und erwarten, dass alle mithalten. Typische Kosten: 40.000 bis 100.000 Pfund, je nach Zahl der Ressourcen und Strenge der Sicherheitsanforderungen.

Öffentliche oder Produkt-APIs bedienen jeden, der sich anmeldet. Selbstbedienungs-Registrierung, Schlüsselverwaltung, veröffentlichte Ratenbegrenzungen, eine Statusseite, nutzungsbasierte Messung, umfassende Dokumentation und ein Supportprozess werden allesamt notwendig. Hängt die Abrechnung an der Nutzung, haben Sie zusätzlich ein Mess- und Abgleichsystem gebaut. Typische Kosten: ab 100.000 Pfund, und der Start ist der Anfang der Ausgaben, nicht ihr Ende.

Ehrlich zu entscheiden, welche Stufe Sie bauen, ist die wertvollste halbe Stunde des Projekts. Die meisten Kostenüberschreitungen in dieser Kategorie entstehen, weil jemand eine interne API abgesteckt hat und drei Monate später feststellt, dass ein Partner sie ohnehin immer nutzen sollte.

Wohin die Kosten der API-Entwicklung wirklich fließen

Bei einer API in Partnerqualität verteilt sich der Aufwand recht vorhersehbar, und selten so, wie die Beteiligten es erwarten.

Etwa ein Fünftel geht in Entwurf und Spezifikation, einschließlich der Diskussionen über die Benennung von Ressourcen, die verschwenderisch wirken und Monate an Inkonsistenz verhindern. Ein weiteres Fünftel entfällt auf die Umsetzung der Endpunkte selbst, also genau auf den Teil, den sich alle vorstellen, wenn sie das Budget freigeben.

Authentifizierung, Autorisierung und Ratenbegrenzung zusammen beanspruchen häufig fünfzehn bis zwanzig Prozent, und mehr, wenn Sie einen vorhandenen Identitätsanbieter anbinden, der eigene Ansichten hat. Dokumentation, Sandbox und etwaige Client-Bibliotheken nehmen einen ähnlichen Anteil ein, was die Leute überrascht, bis sie versuchen, einen guten Einstiegsleitfaden zu schreiben.

Tests, Beobachtbarkeit und Auslieferung verbrauchen den Rest. Dieses letzte Viertel wird am ehesten gestrichen, wenn ein Termin näher rückt, und genau dieses Streichen verwandelt einmalige Baukosten in eine dauerhafte Supportlast.

Wie sich das neben den übrigen Posten eines Lieferbudgets ausnimmt, legt unser Leitfaden zu den Kosten individueller Softwareentwicklung im Umfeld dar.

Entscheidungen, die die Zahl bewegen

Eine Handvoll Entscheidungen erklärt den größten Teil der Streuung zwischen zwei Angeboten.

Synchron oder asynchron. Dauert eine Operation länger als ein bis zwei Sekunden, brauchen Sie ein Auftragsmodell: die Anfrage annehmen, eine Referenz zurückgeben und den Konsumenten abfragen oder einen Rückruf empfangen lassen. Das ist ein deutlich größerer Bau als eine einfache Anfrage mit Antwort, und wer Webhooks anbietet, betreibt nun ein eigenes Zustellsystem mit Wiederholungen, Signaturprüfung und einem Speicher für unzustellbare Nachrichten.

Mandantenfähigkeit. Sicherzustellen, dass ein Kunde niemals die Daten eines anderen sieht, ist leicht beschrieben und leicht auf subtile Weise falsch gemacht. Es sauber zu tun, mit einer Autorisierung, die auf der Datenzugriffsschicht statt in jedem Controller geprüft wird, kostet zusätzlich und ist nicht optional.

Regulatorische Pflichten. Wer personenbezogene Daten, Zahlungsdaten oder Gesundheitsdaten verarbeitet, bekommt Prüfprotokolle, Aufbewahrungsregeln, Verschlüsselungsanforderungen und Nachweispflichten obendrauf. Diese stehen selten in einer ersten Schätzung und sind später nie verhandelbar.

Zusagen zum Servicegrad. Eine API mit vertraglich zugesicherter Verfügbarkeit braucht Redundanz, Alarmierung und jemanden in Rufbereitschaft. Das ist ein Betriebs- und kein Baukostenposten, und er sollte getrennt ausgewiesen werden, damit niemand überrascht wird.

Vorhandene Grundlagen. Auf einer Codebasis aufzubauen, die Authentifizierung, Hintergrundverarbeitung und Monitoring schon mitbringt, ist dramatisch billiger, als bei null anzufangen. Brauchen Sie die darunterliegende Plattform ebenfalls, zeigt unsere Anleitung zum Bau einer serverlosen API mit Cloudflare Workers einen Ansatz, der die Infrastrukturkosten niedrig hält.

Die Kosten, die nach dem Start kommen

Eine API ist ein Versprechen, und Versprechen haben laufende Kosten.

Die Versionierung ist der größte Posten. Sobald externe Konsumenten von Ihren Antwortstrukturen abhängen, können Sie sie nicht mehr frei ändern. Zwei Versionen parallel zu pflegen, während Integratoren migrieren, ist normal, und es bedeutet, dass jede Fehlerbehebung eine Zeit lang zweimal angewendet werden muss. Eine veröffentlichte Abkündigungsrichtlinie mit großzügiger Frist macht das beherrschbar; ihr Fehlen macht jede Verbesserung zur Verhandlung.

Support ist der zweite Posten. Selbst hervorragende Dokumentation erzeugt Fragen, und die Fragen sind technisch genug, dass sie eine Entwicklerin erreichen, statt an einem Servicedesk zu enden. Planen Sie dafür echte Entwicklungszeit ein, besonders in den Monaten, nachdem ein neuer Partner live gegangen ist.

Die Pflege der Dokumentation ist der dritte und der am meisten vernachlässigte. Beispiele, die nicht mehr funktionieren, sind schlimmer als gar keine Beispiele, und sie zerstören Vertrauen schneller als ein Ausfall.

Als Planungsgröße rechnen Sie jährlich mit fünfzehn bis fünfundzwanzig Prozent der ursprünglichen Baukosten, um eine Partner-API oder öffentliche API gesund zu halten. Ist die API selbst eine Erlösquelle, behandelt unser Leitfaden zu Software-Lizenzmodellen die kaufmännische Seite.

Wie Sie verhindern, dass sich das Projekt verdoppelt

Drei Gewohnheiten halten API-Projekte innerhalb ihrer Schätzung.

Schreiben Sie zuerst die Spezifikation und lassen Sie sie von einem echten Konsumenten prüfen, bevor die Umsetzung beginnt. Eine Stunde Rückmeldung von dem Team, das später tatsächlich integriert, spart Wochen an Nacharbeit und legt die Anforderung offen, die niemand erwähnt hat.

Bauen Sie einen einzigen Endpunkt vollständig, durch Authentifizierung, Fehlerbehandlung, Dokumentation, Tests und Monitoring hindurch, bevor Sie die anderen zwanzig bauen. Der erste zeigt die wahren Kosten je Endpunkt, und er tut es, solange das Budget die Nachricht noch verkraftet.

Seien Sie unbarmherzig bei der anfänglichen Ressourcenliste. Die meisten APIs starten mit mehr Endpunkten, als irgendwer nutzt, und jeder ungenutzte Endpunkt will dokumentiert, getestet, abgesichert und versioniert werden, solange es ihn gibt. Liefern Sie die kleinste nützliche Oberfläche aus und erweitern Sie sie, sobald echte Nutzung zeigt, was fehlt.

Bauen Sie eine API, die andere gern integrieren

Mecanik entwirft und baut APIs im Rahmen unserer individuellen Softwareentwicklung , von internen Diensten bis zu öffentlichen Produkt-APIs mit Selbstbedienungs-Onboarding. Wir behandeln Spezifikation, Dokumentation und Sandbox als Arbeitsergebnisse statt als Nachgedanken, weil genau sie darüber entscheiden, ob eine Integration überhaupt gelingt.

Stehen Sie auf der anderen Seite dieses Problems und nutzen die API eines anderen, statt selbst eine zu veröffentlichen, behandelt unser Leitfaden zur Integration fremder APIs , worauf zu achten ist. Andernfalls sagen Sie uns, wer die Konsumenten sind und was sie tun müssen, und wir stecken es Stufe für Stufe ab, damit Sie genau sehen, was jedes Ambitionsniveau kostet.

Siehe auch: Software-Entwicklung in Großbritannien outsourcen , CRM- und ERP-Integration: Kosten, Wege, Fallstricke , Mainframe-Modernisierung: Rewrite, Refactor oder Replatform .

Häufig gestellte Fragen

Was kostet die individuelle API-Entwicklung? Eine interne API kostet typischerweise 10.000 bis 30.000 Pfund, eine Partner-API 40.000 bis 100.000 und eine öffentliche Produkt-API mehr als 100.000. Das Publikum treibt den Preis weit stärker als die Zahl der Endpunkte, denn externe Konsumenten verlangen Dokumentation, Sandboxes, Versionierung und Support.

Wie lange dauert der Bau einer individuellen API? Ein interner Dienst braucht meist vier bis acht Wochen. Eine API in Partnerqualität dauert in der Regel drei bis fünf Monate einschließlich Dokumentation und Testumgebung. Öffentliche APIs mit Selbstbedienungs-Onboarding und Nutzungsmessung brauchen häufig sechs Monate oder mehr bis zum Start.

Was macht die API-Entwicklung teurer als erwartet? Dokumentation, Sandbox-Umgebungen, Ratenbegrenzung je Konsument, Versionierungsunterstützung und Beobachtbarkeit. Diese Posten tauchen in frühen Schätzungen selten auf und machen bei einer Partner-API oder öffentlichen API zusammen oft die Hälfte des Gesamtaufwands aus.

Sollte ich eine REST- oder eine GraphQL-API bauen? REST bleibt die sicherere Voreinstellung für Partner-APIs und öffentliche APIs, weil Werkzeuge, Caching und Vertrautheit unter Entwicklern breiter sind. GraphQL passt zu interner Nutzung und reichhaltigen Client-Anwendungen mit flexiblen Abfragen, verschiebt die Kosten aber in Abfragekomplexitätsgrenzen und Autorisierung.

Welche laufenden Kosten entstehen nach dem Start einer API? Planen Sie jährlich fünfzehn bis fünfundzwanzig Prozent der Baukosten ein. Das deckt die Pflege paralleler Versionen während Abkündigungsfristen, Entwicklungszeit für Integrationsfragen, die Aktualisierung der Dokumentation und das Monitoring, das externe Konsumenten erfordern.