Was ist API-Design?

Unter API-Design versteht man die Entwicklung von APIs (Application Programming Interfaces), die Entwicklern und Nutzern Daten- und Anwendungsfunktionen zur Verfügung stellen. APIs sind für moderne Organisationen sehr wichtig, da sie diverse neue Funktionen für alle Bereiche bieten, vom operativen Geschäft über Produkte bis hin zu Partnerschaftsstrategien. Die meisten Unternehmen fragen nicht mehr länger, ob sie sich mit API-Programmen befassen sollen, sondern wie es gemacht wird.

Ein effektives API-Programm muss auf der übergeordneten Unternehmensstrategie aufsetzen und zur Erfüllung ihrer Ziele beitragen. Sie wissen, dass Sie es mit einer tollen Strategie zu tun haben, wenn Sie folgende Fragen ohne Umschweife beantworten können:

1. Aus welchem Grund möchten wir APIs implementieren?
2. Welche konkreten Ergebnisse möchten wir damit erzielen?
3. Wie planen wir die API-Ausführung, um diese Ziele zu erreichen?

Das Warum

Diese Frage wird häufig falsch interpretiert. Statt nach dem Wert einer API zu fragen, sollten Sie sich auf den Wert ihrer Auswirkungen konzentrieren. Denn das Kerngeschäft der Organisation ist wichtig, nicht notwendigerweise die API selbst. Eine API ist dann wertvoll, wenn sie neue Arten des Zugriffs auf die bereits bestehenden und bereitgestellten Werte einer Organisation ermöglicht.

Ein weiterer Fehler besteht darin, zu glauben, dass eine API nur dann wertvoll ist, wenn die Nutzer bereit sind, dafür zu zahlen. Das ist nur dann richtig, wenn die API selbst das Produkt ist. In den meisten Fällen ist dies allerdings nicht der Fall. Durch APIs werden in der Regel andere Kennzahlen gesteigert, z. B. Umsatz, Empfehlungen verbundener Unternehmen, Markenbewusstsein usw. Der Wert einer API für den Nutzer ist das Ergebnis des API-Aufrufs (Serviceanfrage/-antwort) und nicht der Aufruf selbst.

In einer vom Cutter Consortium und von Wipro mit 152 Organisationen durchgeführten Umfrage werden als häufigste geschäftliche Beweggründe für ein API-Programm die Umsatzsteigerung, der Einsatz neuer Geschäftsmodelle, kürzere Markteinführungszeiten und die Entwicklung neuer Absatzkanäle genannt. Die technologischen Beweggründe bestehen darin, die Anwendungs- und Mobilgeräteintegration zu verbessern und die Anbindung zusätzlicher Geräte zu unterstützen. Damit es sich für ein Unternehmen lohnt, in APIs zu investieren, müssen die Vorteile auf der Hand liegen.

Das Was

Die zweite Frage sollte lauten: „Welche konkreten Ergebnisse möchten wir damit erzielen?". Oder anders formuliert: „Welchen Nutzen haben APIs eigentlich und wie wirken sie sich auf meine erweiterte Geschäftsstrategie aus?"

Sowohl die interne als auch die externe Sichtweise auf eine Organisation kann dabei helfen, das Was der API zu definieren. Intern geht es in erster Linie um die spezifischen und wertvollen Assets eines Unternehmens. Je wertvoller und spezieller die angebotenen Services und Ressourcen sind, desto besser eignen sie sich für ein API-Programm.

Eine Organisation, die über spezielle Daten verfügt, könnte diese Ressource nutzen, indem sie den Zugriff darauf via API erlaubt. Besondere Inhalte, Daten und Services wiederum machen den Zugang zur API extrem wertvoll.

Um den Wert einer API für ein Unternehmen bestimmen zu können, muss sowohl die interne als auch die externe Sichtweise
geprüft werden. Die Entscheidung bezüglich des Was ist deshalb meist eine Kombination dieser beiden Sichtweisen.

Genauer gesagt, während sich das Warum nur sehr selten ändert, kann das Was entsprechend den externen Faktoren (wie Märkte, technische Überlegungen oder wirtschaftliche Bedingungen) erheblich variieren. Dazu kann es vorkommen, dass sich die interne Einschätzung des Werts eines Assets ändert, was wiederum den Bestimmungszweck einer API beeinflussen kann.

Das Wie

Bei der abschließenden Frage „Wie muss unser API-Programms aussehen, damit es unsere Ziele erfüllt?" geht es in erster Linie um Implementierung und Ausführung.

So sollten sich Teams folgende Fragen stellen:

• Welche Technologie wird zur API-Entwicklung verwendet?
• Wie werden die APIs konzipiert?
• Wie werden die APIs gepflegt?
• Wie werden die APIs innerhalb der Organisation gefördert oder an die Außenwelt vermarktet?
• Welche Ressourcen sind verfügbar?
• Wer sollte zum Team gehören?
• Wie können wir den Erfolg mit den gesetzten geschäftlichen Zielen vergleichen?

API-Teams sind Produkt-Teams am ähnlichsten, denn egal ob Sie es mit internen oder externen Kunden zu tun haben, Sie sind für die Entwicklung, Bereitstellung, Ausführung und Optimierung der Infrastruktur verantwortlich, auf die sich andere verlassen.

Wie Produkt-Teams auch können API-Teams sehr unterschiedlich sein. Normalerweise sollten zum Team gehören: ein produktorientierter Mitarbeiter, der Strategie und Ziele überwacht, designorientierte Mitglieder, die Best Practices beim API-Design umsetzen, Ingenieure, die die API-Technologie implementieren und Operations-Mitarbeiter, die die API ausführen.

Im Laufe der Zeit können weitere Personen hinzukommen, z. B. Mitglieder der Support- und Community-Teams, API-Evangelisten, Sicherheitsfachleute und andere.

John Musser hat in seinem Vortrag bei der O’Reilly Open Source Convention die fünf wichtigsten Voraussetzungen für den Erfolg einer API vorgestellt. Eine gute API sollte:

1. Einen wertvollen Service liefern
2. Einen Plan und ein Geschäftsmodell haben
3. Kompakt, flexibel und einfach zu integrieren sein
4. Gemanagt und gemessen werden
5. Die Entwickler gut unterstützen

Punkt 1 ist ganz besonders in Bezug auf das Warum Ihres API-Programms wichtig. Das Leistungsversprechen ist der Hauptfaktor für den Erfolg einer API. Wenn sie das falsche Versprechen (oder gar keines) besitzt, ist die Suche nach interessierten Nutzern sehr schwierig oder gar unmöglich.

Praktisch jedes Unternehmen mit einem Produkt, egal ob digital oder physisch, kann über eine API Werte
generieren, wenn sie mit aktuellen Angeboten verknüpft ist und/oder diese aufwertet. Solange eine API so strukturiert ist, dass sie bedeutungsvolle Use Cases für Entwickler bietet, wird sie auch einen Mehrwert generieren.

Die Suche nach dem Wert Ihrer API und die Beschreibung des Werts sind ein iterativer Prozess. Im ersten Schritt werden die Aufgaben definiert, die durchgeführt werden sollen. Beispiel:

• Automatische Versendung von Kommunikationen an Team-Mitglieder in Notfällen
• Sicherung kritischer Dateien zum Schutz gegen Verlust
• Entnahme von Datenproben, um bestimmte Events zu erkennen

Als Nächstes ermitteln Sie die speziellen Herausforderungen, mit denen es die Nutzer vor, während oder nach der Durchführung einer Aufgabe zu tun haben:

• Gewährleistung einer zuverlässigen Sendung nach mehreren Versuchen, Fehlererkennung, die Gefahr der Versendung mehrerer Nachrichten statt nur einer und Integration mit unterschiedlichen Messaging-Systemen je nach Nutzerstandort
• Gewährleistung einer sicheren Datenübertragung bei gleichzeitiger Minimierung der Bandbreite
• Handhabung riesiger Datenvolumina und der Versuch, diese in Echtzeit zu korrelieren

Der dritte Schritt ist die Zusammenfassung der potenziellen Vorteile für den Nutzer:

• Versendung anderer Benachrichtigungsarten, die eher eine Chance statt eine Warnung darstellen
• Eliminierung anderer Storage-Geräte, wenn die Zuverlässigkeit Ihren Anforderungen entspricht
• Automatische Ausführung von Maßnahmen bei bestimmten Ereignissen

Bei der Analyse dieser Problempunkte sollten Sie in großen Dimensionen denken und Dinge wie Support, Dokumentation oder Entwicklerportale auflisten, also alles, was ein Nutzer in Anspruch nehmen könnte. Erläutern Sie dann, wie Sie einige der Problempunkte reduzieren oder eliminieren möchten, mit denen API-Nutzer vor, während oder nach der Durchführung einer Aufgabe zu tun haben oder die die Durchführung unmöglich machen. Beschreiben Sie anschließend, wie Sie Werte für Ihre API-Nutzer schaffen möchten.

Indem Sie diesen Prozess nutzen, können die drei oben genannten Beispiele zu folgenden Ergebnissen führen:

• Zu einer Multi-Channel-Messaging-API, bei der Nachrichten mit einem einzigen Aufruf versendet werden und die automatische Zustellversuche durchführt, bis der Empfang garantiert ist (z. B. Twilio, PagerDuty)
• Zu einer API zur Storage-Synchronisierung, bei der optimierte Aufrufe durchgeführt werden, die effizient prüfen, ob neue Versionen synchronisiert werden müssen (z. B. Bitcasa, Box)
• Zu einer API, die verschiedene Datenquellen in einen konfigurierbaren Stream aggregiert, der gefiltert, durchsucht und auf einfache Weise gehandhabt werden kann (z. B. GNIP, DataSift)

Um größere Klarheit zu erzielen, können Sie schließlich als Übung verschiedene Aussagen formulieren, die deutlich machen, wie API und Nutzerprofil zusammenpassen. Wenn Ihnen diese Formulierung schwerfällt, dann sollten Sie das API-Modell neu überdenken. Möglicherweise müssen Sie API-Features hinzufügen, prüfen, neu definieren oder entfernen. Es kann auch sein, dass Ihre API einen großen Mehrwert darstellt, Sie jedoch die falsche Nutzergruppe ausgewählt haben.

Wenn Sie Ihre Aussagen über das Zusammenpassen von API und Nutzerprofil auf eine übergeordnete Aussage reduzieren können, erhalten Sie das Leistungsversprechen für Ihre APIs. Im Falle der Messaging-API kann das folgendermaßen aussehen:

Unsere Messaging-API bietet Unternehmensentwicklern eine zuverlässige, garantierte und latenzfreie Messaging-Funktion für zentrale Geschäftsanwendungen. Dazu wird die API mit SDKs für die gängigsten Programmiersprachen unterstützt, die eine schnelle Integration ermöglichen.

In manchen Fällen denken Sie vielleicht: „Das scheint mir ziemlich aufwändig zu sein. Immerhin entwickeln wir ja nur eine interne API." Vergessen Sie nie, dass der Mehrwert ausschlaggebend ist, und zwar auch bei internen Use Cases. Ein mehrdeutiges Leistungsversprechen macht es extrem schwer, andere Teams für die API zu interessieren. Eine wohldurchdachte Formulierung hingegen sorgt dafür, dass das API-Programm reibungslos umgesetzt werden und einen wertvollen Beitrag zum Unternehmen leisten kann.

Um den Wert Ihres API-Programms bestimmen zu können, sind folgende fünf Fragen hilfreich:

1. Wer sind die Nutzer? Bei dieser Frage geht es um die Beziehung dieser Nutzer zu Ihnen (ob es sich um aktuelle Kunden, Partner oder externe Entwickler handelt), ihre Rolle (ob sie Datenwissenschaftler, Mobilentwickler oder Operations-Mitarbeiter sind) sowie ihre Anforderungen oder Präferenzen.
2. Welche Problempunkte lösen wir für den Nutzer und/oder welche Werte schaffen wir für ihn? Diese Frage sollte im Zusammenhang mit der Geschäftstätigkeit sowie den Herausforderungen und Vorteilen für den Kunden aus dem Leistungsversprechen sowie der Frage beantwortet werden, ob eine zentrale Anforderung erfüllt (Problempunkt oder Gewinnmöglichkeit) oder welche Kennzahl für den Nutzer verbessert wird (Geschwindigkeit, Ertrag, Kosteneinsparungen, Möglichkeiten für neue Prozesse/Produkte).
3. Welche Use Cases werden von Ihrer API unterstützt? Identifizieren Sie mithilfe des Leistungsversprechens die Problemlösungen für Ihre Nutzer oder die Vorteile durch die API, die für Ihre Organisation und die Nutzer am wertvollsten sind. Planen Sie Ihre API im Hinblick auf die Nutzung dieser Use Cases.
4. Wie lässt sich der Wert für den Nutzer im Laufe der Zeit steigern? „Planen Sie Ihr Leistungsversprechen im Hinblick auf zukünftige Veränderungen. Welche sind die wichtigen anstehenden Meilensteine bezüglich von internen oder externen Änderungen?
5. Welche internen Werte schaffen Sie für Ihre Organisation? Berücksichtigen Sie dabei interne Vorteile und welchen Wert die API für Ihr Unternehmen haben kann.

Die klare Definition des Werts einer API ist ein wichtiger Meilenstein für das Design Ihres API-basierten Programms. APIs verursachen jedoch auch Kosten, die dem Mehrwert gegenübergestellt werden sollten. Auch wenn der Wert nicht als monetäre Größe gemessen werden kann, muss er dennoch echt sein, z. B.:

• Was ist das aktuelle Kerngeschäft der Organisation?
• Wie kann eine API eingesetzt werden, um das geschäftliche Wachstum zu beschleunigen oder zu verbessern?

In manchen Fällen lassen sich mit APIs außerhalb des aktuellen Geschäftsmodells einer Organisation komplett neue Geschäftschancen schaffen. Doch selbst in solchen Fällen ist es so, dass sie einfach nur bestehende Assets oder Know-how auf eine neue Art und Weise nutzen.

Zusammenfassend lässt sich sagen, dass es drei Gründe dafür gibt, warum die Festlegung auf ein geeignetes Geschäftsmodell für das Design effizienter APIs so wichtig ist:

1. Die Festlegung auf ein geeignetes Geschäftsmodell rückt den Wert der API in den Fokus der Organisation und unterstützt Entscheidungen zugunsten eines langfristigen API-Programms. Ohne eine langfristige Zusage stehen meist nicht die erforderlichen Ressourcen zur Verfügung, um die Aufgaben zu bewältigen, die für die Einrichtung und Ausführung eines effizienten API-Programms notwendig sind.
2. Die Festlegung auf ein geeignetes Geschäftsmodell hilft, die Produktfunktionen zu definieren, die von Drittparteien benötigt werden und die Umsätze generieren.
3. Die Festlegung auf ein geeignetes Geschäftsmodell gewährleistet, dass auf die entsprechenden Rollen und Zuständigkeiten innerhalb einer Organisation geachtet wird, und außerdem darauf, wer von dem durch die API generierten Wert profitiert. Deswegen muss ebenfalls definiert werden, wovon genau die Nutzer durch die Verwendung der API profitieren und wie sich dieser Nutzen zum Nutzen des API-Anbieters verhält.

Ein gutes API-Design enthält einige Kernprinzipien, die möglicherweise nicht auf die gleiche Weise implementiert werden. Dazu eine Analogie: Alle Autos verfügen über Lenkrad, Brems- und Gaspedal. Zwar können sie in Sachen Warnblinkanlage, Kofferraum oder Radio je nach Modell voneinander abweichen, allerdings wird ein erfahrener Autofahrer in fast allen Fällen in der Lage sein, einen Mietwagen zu steuern.

Es ist genau diese Art der „Fahrbereitschaft", auf die es guten API-Teams ankommt, also auf APIs, für deren Nutzung der routinierte Anwender nur rudimentäre oder gar keine Anweisungen benötigt.

Einfachheit

Die Einfachheit des API-Designs hängt vom Kontext ab. Ein bestimmtes Design kann sich für einen Use Case einfach, für einen anderen als komplex erweisen, weshalb die Feinheiten der API-Methoden ausgeglichen sein müssen. Aus diesem Grund sollte man in Sachen Einfachheit mehrere Ebenen berücksichtigen, darunter:

• Datenformat. Support für XML, JSON, proprietäre Formate oder eine Kombination daraus.
• Methodenstruktur. Methoden können allgemein sein und einen breiten Satz an Daten zurückgeben oder im Falle von gezielten Anfragen sehr spezifisch. Solche Methoden werden üblicherweise in einer bestimmten Sequenz aufgerufen, um spezielle Use Cases zu erreichen.
• Datenmodell. Das zugrundeliegende Datenmodell kann dem, was letztlich mit der API abgerufen wird, sehr ähnlich sein oder stark davon abweichen. Dieser Aspekt wirkt sich auf Nutzbarkeit und Verwaltbarkeit aus.
• Authentifizierung. Authentifizierungsmechanismen können unterschiedliche Stärken und Schwächen haben. Welcher für Sie geeignet ist, hängt vom Kontext ab.
• Nutzungsrichtlinien. Rechte und Quoten für Entwickler sollten einfach verständlich und benutzerfreundlich sein.

Die Einfachheit einer API kann ihre Flexibilität beeinträchtigen. Bei einfachen APIs kann es vorkommen, dass sie zu individuell sind, nur zu spezifischen Use Cases passen und nicht genügend Flexibilität für andere bieten.

Um einen solchen Konflikt zu vermeiden, müssen Sie zuerst die Kriterien des potenziellen Nutzungsbereichs bestimmen, darunter zugrundeliegende Systeme und Datenmodelle, und welches Subset dieser Operationen durchführbar und wertvoll ist. Tun Sie Folgendes, um die richtige Balance zwischen Einfachheit und Flexibilität zu finden:

• Isolieren Sie atomare Operationen. Sie können den gesamten Raum abdecken, indem Sie atomare Operationen kombinieren.
• Identifizieren Sie die gängigsten und wertvollsten Use Cases. Entwerfen Sie eine zweite Schicht mit Meta-Operationen, die mehrere atomare Operationen für solche Use Cases vereinigen.

Mit dem HATEOAS-Konzept (Hypermedia as the Engine of Application State) lässt sich die Flexibilität weiter verbessern, weil es Runtime-Änderungen in API- und Client-Operationen ermöglicht. HATEOAS erhöht in der Tat die Flexibilität, weil es die Versionierung und Dokumentation vereinfacht. Allerdings müssen beim API-Design viele Fragen berücksichtigt werden.

Um eine sorgfältige Planung Ihres API-Designs zu gewährleisten, stellen Sie sich folgende fünf Fragen:

1. Wurde die API für den Support unserer Use Cases entwickelt? Der nächste Schritt nach der Identifizierung der wichtigsten Use Cases liegt darin, die API so zu entwerfen, dass diese Use Cases unterstützt werden. Flexibilität ist wichtig, sodass Use Cases berücksichtigt werden sollten, die zwar weniger häufig sind, aber trotzdem unterstützt werden sollten, um Raum für Innovationen zu lassen.
2. Nutzen wir RESTful APIs nur um ihrer selbst willen?RESTful APIs liegen voll im Trend, Sie sollten diesem aber nicht folgen, nur weil alle anderen es tun. Es gibt sicherlich Use Cases, für die RESTful Apps gut geeignet sind, dann gibt es aber noch diejenigen, die einen anderen Architekturstil bevorzugen, wie etwa GraphQL.
3. Haben wir gerade unser Datenmodell exponiert, ohne Use Cases zu berücksichtigen?„ APIs sollten mit einer Schicht geschützt werden, die von Ihrem aktuellen Datenmodell getrennt ist. Als allgemeine Regel gilt: Vermeiden Sie APIs mit einer direkten Verbindung zu Ihrer Datenbank – auch wenn es Fälle gibt, in denen dies erforderlich ist.
4. Welche geographischen Regionen sind am wichtigsten und ist die Planung unserer Rechenzentren darauf ausgelegt?„ Das API-Design muss auch nicht funktionelle Elemente wie Latenzzeiten und Verfügbarkeit berücksichtigen. Stellen Sie sicher, dass die Rechenzentren dort positioniert sind, wo Sie Ihre größten Nutzerkonzentrationen haben.
5. Synchronisieren wir das API-Design mit unseren anderen Produkten? Wenn Sie außer der API weitere Produkte herstellen, sollten Sie Ihr API-Design an diesen Produkten ausrichten. Es kann jedoch auch sein, dass Sie Ihr API-Design komplett von den anderen Produkten entkoppeln möchten. Auch in diesem Fall müssen Sie klare Pläne zur Entkopplung des API-Designs von anderen Produkten entwickeln und diese sowohl intern als auch extern kommunizieren.

Eine wichtige Kennzahl zur Verbesserung des API-Designs zwecks einfacher Nutzung ist die „Time to first hello world" (TTFHW). Mit anderen Worten, wie lange dauert es, bis ein Entwickler mithilfe Ihrer API ein Produkt erstellt, das ein Minimum an Durchführbarkeit aufweist? Dies ist eine sehr gute Möglichkeit, sich in einen Entwickler zu versetzen, der Ihre API testen möchte, um herauszufinden, was er braucht, damit etwas funktioniert.

Wenn Sie Beginn und Ende einer TTFHW-Kennzahl definieren, sollten Sie so viele Aspekte der Entwicklerbeteiligung wie möglich abdecken. Optimieren Sie sie dann auf maximale Geschwindigkeit und Benutzerfreundlichkeit.

Ein schneller Prozess schafft Vertrauen beim Entwickler dahingehend, dass die API gut organisiert ist und alle Erwartungen erfüllt werden. Zögern Sie den „Erfolgsmoment" auf keinen Fall hinaus, weil Sie sonst Entwickler abschrecken.

Neben dem TTFHW-Konzept empfehlen wir mit „Time to first profitable app" (TTFPA) eine weitere Kennzahl. Hier ist der Sachverhalt etwas komplexer, denn die Interpretation des Adjektivs „profitable" (rentabel) variiert je nach API und Geschäftsstrategie. Trotzdem sind diese Überlegungen nützlich, weil Sie dabei über Aspekte der API-Operationen als Bestandteil des API-Programms nachdenken müssen.

Die zwei zugrundeliegenden Prinzipien der Entwicklererfahrung sind:

1. Entwerfen Sie ein Produkt oder einen Service, das/der für die Entwickler einen eindeutigen Wert bietet sowie eine spezielle Herausforderung oder Möglichkeit anspricht. Diese können monetäre sowie andere Werte sein, darunter die Vergrößerung der Reichweite, Steigerung des Markenbewusstseins, indirekte Umsätze, Reputation der Entwickler oder einfach die reine Freude an einer tollen Technologie, die funktioniert.
2. Das Produkt muss problemlos zugänglich sein. Dazu kann gehören: eine einfache Registrierung (oder gar keine), Zugriff auf Testfunktionen, eine tolle Dokumentation sowie eine Menge an kostenlosem und sauberem Quellcode.

Wir empfehlen, die meisten API-Programme mit einem Entwicklerprogramm auszustatten, und zwar egal ob Sie Ihre API der Öffentlichkeit oder nur Partnern oder internen Nutzern bereitstellen. Die Voraussetzungen können je nach Zielpublikum mehr oder weniger umfangreich sein.

Entwickler-Portal

Das Entwickler-Portal ist das wichtigste Element eines Entwicklerprogramms oder auch der primäre Zugangspunkt (Anmeldung, Zugriff auf und Nutzung Ihrer APIs) durch Entwickler. Der Zugriff auf Ihre API durch Entwickler sollte benutzerfreundlich sein. Damit soll in erster Linie ein schneller Einstieg gewährleistet werden.

Und TTFHW ist dafür die perfekte Kennzahl. Sie sollten auch darüber nachdenken, den Anmeldeprozess zu optimieren, je einfacher, desto besser. Eine empfohlene Best Practice ist, dass Entwickler in der Lage sein sollten, Ihre APIs ohne jegliche Anmeldung aufzurufen und ihr Verhalten zu untersuchen (Anfrage und Antwort). Um die Lernkurve noch weiter zu vereinfachen, sollten Sie über die Bereitstellung zusätzlicher Inhalte wie Erste-Schritte-Anleitungen, API-Referenzdokumentation oder Quellcode nachdenken.

Beschleunigung über das Partnernetzwerk

Als API-Anbieter sind Sie Teil eines Netzwerks aus Partnern und Anbietern. Diese Partner verfügen meist über ihre eigenen Content-Distribution- und Kommunikationsnetzwerke und -Tools. Sie sollten deshalb Allianzen ermitteln, mit denen Sie den Einsatz Ihrer API fördern können. Solche Allianzen bilden sich meist, wenn APIs als Ergänzung dienen und in Kombination mit anderen einen Geschäftswert für Entwickler darstellen.

Fragen bezüglich der Bewertung Ihrer Entwicklererfahrung:

1. Wie können wir den Wert der API schon in den ersten fünf Minuten erläutern? Entwickeln Sie einen „Elevator Pitch" zum Leistungsversprechen Ihrer API, der auf Entwickler ausgerichtet ist.
2. Was ist unsere TTFHW und TTFPA und wie kann man sie reduzieren? Dies ist eine leistungsstarke Methode, die Entwicklerfreundlichkeit Ihrer API im Hinblick auf die End-to-End-TTFHW zu verbessern. Sie sollten die Kennzahlen TTFHW und TTFPA bei allen Elementen berücksichtigen, die zur Entwicklererfahrung hinzugefügt werden (wie in Portalen), sowie bei allen Aspekten der API, die sich ändern.
3. Wie sieht der Onboarding-Prozess für Entwickler aus und ist er so benutzerfreundlich wie möglich? Er sollte mit den Use Cases Ihrer API abgestimmt sein. Das Sicherheitsniveau muss für sensible APIs oder Datenzugriffe natürlich höher sein und ggf. als formale Vereinbarung festgelegt werden. Für alles andere sollte dieser Aspekt einfach und unkompliziert gehandhabt werden, um möglichst schnelle Entwicklererfolge (TTFHW) zu gewährleisten.
4. Reicht das immer noch aus, um die API für Entwickler attraktiv zu machen? Prima, wenn Sie das ideale Leistungsversprechen gefunden haben und Entwickler sich für Ihre API registrieren. Vergessen Sie nicht: Wenn Sie den Entwicklern helfen, erfolgreich zu sein, können Sie dadurch deren Anzahl beibehalten oder gar erhöhen.
5. Wie unterstützen wir Entwickler, wenn sie auf Probleme stoßen? Wir setzen auf den Self-Service-Ansatz, der Sie bei einer Skalierung unterstützt. Die meisten Fragen der Entwickler lassen sich mithilfe einer guten Dokumentation, FAQs und Foren beantworten. Self-Service hat sicher auch seine Grenzen, weshalb für detaillierte Fragen und andere Komplikationen (wie z. B. Rechnungsprobleme) ein Supportmechanismus implementiert werden sollte.
6. Unterstützt unsere Dokumentation Innovationen? Welche Unterstützung gibt es für Entwickler, die von normalen Use Cases abweichen oder etwas Neues ausprobieren möchten? Tolle Ideen können von überall her kommen.