“Ich plane gerade eine App, welche dies und jenes kann und natürlich sollen die Funktionalitäten auch 3rd Party Entwickler über unsere API nutzen können.” Falls das jemanden bekannt vorkommt: Ich kenn das in den unterschiedlichsten Ausführungen und hatte diese Gedanken z.B. hier mal niedergeschrieben.
Bevor man loslegt, sollte man nochmal überlegen: Brauch ich das wirklich? Ein paar Gedanken dazu aus meiner “Web-Dev” Ecke…
Public vs. Privat/Internen APIs
Differenzieren wir am Anfang zwischen öffentlichen APIs, wie z.B. die APIs von Twitter und internen APIs. Interne können z.B. REST Services sein, welche von diversen Javascripts auf der Seite benutzt werden oder kleine Services, welche ich per HTTP irgendwie ansprechen kann. Diese sind meist genau für den Einsatzzweck bestimmt bzw. decken nur einen kleinen Funktionsumfang ab.
Bei den internen würde ich den Begriff “API” etwas unglücklich finden, solange sie nur dem Selbstzweck dienen.
Schauen wir uns eher den Gedanken an, dass plötzlich 3rd Party Entwickler unsere Services nutzen wollen.
Wann benötigt man eine API?
(Natürlich benötigt man eine API, wenn man Dev-Tools oder Frameworks herstellt – dann ist das ja das Produkt bzw. die “App”. Beispiel hier wäre z.B. RavenDB. Ohne API = Nutzlos.)
Anderer Fall ist, dass man wirklich aktiv mehrere “Apps” plant, welche auf die große Plattform zugreifen. iPhone App und WebApp holen sich die Daten von einem Service (welcher etv. auch in der WebApp zu finden sein kann) = macht auch Sinn.
3rd Party Entwickler zeigen ernsthaftes Interesse oder man möchte seine App zur Plattform umfunktionieren = jepp, auch da macht es Sinn.
Wenn man sich die Zeit einfach nehmen will und das aus Spaß macht: Gern!
Wann benötigt man keine API?
Wenn man sein Produkt / Seite generell erstmal “zum Fliegen bringen muss/will”, dann ist eine “public”-API wirklich hinderlich. Mehr Schichten bedeutet auch mehr Code, welcher geschrieben werden muss. Änderungen im Datenmodell werden aufwändiger – insbesondere wenn es doch schon irgendwelche 3rd Party Entwickler gibt!
Eine API sie zu knechten…
Eine sinnvolle API sich zu überlegen kostet Zeit und erfordert am Ende wieder einiges an Zeit, Geld und die Wahl der entsprechenden Tools.
… ins dunkel zu treiben…
Wer ernsthaft eine “public” API plant, sollte sich auch Gedanken um eine Dokumentation machen. Ohne Dokumentation nützt es auch nichts.
… und ewig zu binden.
Eine API ist eine Art Vertrag, den man nicht brechen sollte. Das kann insbesondere bei einem jungen Projekt recht kompliziert werden. Anderer Fall wäre natürlich, man bricht mit der Abwärtskompatibilität, aber dann wäre das ganze API Thema ohnehin wieder bei 0.
Aufwände über Aufwände:
Wenn nur “das eigene Frontend” eine API benutzt, dann könnte Fehler in der API “versteckt” bleiben, einfach aus dem Grund, dass z.B. bestimmte Aktionen im Frontend gesperrt sind, aber theoretisch über API manuell ausgeführt werden könnten. Diese Sachen kosten natürlich enorm viel Zeit. Die Schnittstelle Versionierbar zu machen, Datenmodelle evtl. anzupassen und die “Backend-Systeme” flexibel zu halten – huiuiui.
Also… braucht ihr das wirklich?
Wer von Anfang an mit dem Konzept der “public” APIs gehen möchte, der hat viel Arbeit vor sich. Natürlich kann das ganze Experiment auch glücken: Twitters Aufstieg begann mit den APIs, allerdings weiß ich nicht in welcher “Projektphase” sie damals noch steckten. Ich habe bei meinem KnowYourStack.com Projekt jedenfalls schon mehr als einmal die “Richtung” des Projekts geändert – da bringt die API wirklich nicht viel, ausser das man sich auf die Schulter klopfen kann.
Noch zwei Blogposts, welche den Anstoß für den Blogpost gaben:
