API First

Einführung

Beim API First Ansatz spielt die API die Hauptrolle, sie kommt an erster Stelle und stellt selbst ein Produkt mit Mehrwert dar. Als Schnittstellenbeschreibung z.B. im OpenAPI Format wird die API zu Beginn entwickelt. Man spricht von API Design Frist, einem wichtigen Bestandteil von API First. Im Gegensatz dazu steht API Last, bei dem eine API einer Anwendung nachträglich hinzugefügt wird, um gezielt konkrete Anwendungsfälle zu unterstützen.

API First hat den Anspruch und das Ziel alle Funktionalität wiederverwendbar über die API zur Verfügung zu stellen und so Service-Komposition zu ermöglichen. Bei der Service- oder API-Komposition werden Bausteine über die Schnittstelle zu neuen hochwertigeren Bausteinen zusammengesetzt.

Von API First verspricht man sich:

  • Konsistente Schnittstellen mit hoher Qualität
  • Gute Developer Experience für die Entwickler
  • Wiederverwendbarkeit
  • Unterstützung der digitalen Transformation

Zunächst erscheint API First logisch. In der Praxis lässt sich API First nicht so wie geplant umsetzen und der Ansatz ähnelt in seiner Top-Down Vorgehensweise dem Vorgehen in der Service-orientierten Architektur, die mit vergleichbaren Ansprüchen gescheitert ist.

API-First Kritik

API-First ist ein Vorgehensmodell für die Entwicklung von Systemen von der Analyse der Anforderungen bis zur Umsetzung. Die Beschreibung der Schnittstelle in Form eines OpenAPI Dokumentes wird jeweils an den nächsten Schritt weitergegeben.

Die folgenden Punkte sehen wir bei einem Vorgehen nach API First kritisch:

  • Das Vorgehen ist nicht agil und gleicht dem starren Wasserfallmodell
  • Das Design der Schnittstelle erfolgt nicht Anwendungsfall-getrieben nach Bedarf
  • Das API soll 100% der Funktionalität eines Systems abdecken
  • Der Fokus liegt auf der Wiederverwendung

Die Punkte gleichen den Schwächen, an denen bereits die Service-orientierte Architektur krankte.

Der API First Prozess wird im Video mit dem #Wasserfall-Modell verglichen und gezeigt, dass das Vorgehen ein gut getarnter, starrer Wasserfall darstellt. Feedback Schleifen zu Beginn zwischen Anforderungsanalyse und Design täuschen darüber hinweg, dass eine vollständige API-Beschreibung zu Beginn eines Projektes zu einem starren Vorgehen und zu Problem bei der Versionierung führt.