API-First Design: Wenn die Website nur "ein" Kanal von vielen ist

Früher (2015) bauten wir Websites so:

1. Wir installierten WordPress.
2. Wir wählten ein Theme.
3. Wir schrieben den Content direkt in den Editor, fertig formatiert für den Browser.

Das Problem 2026: Ihr Content muss nicht nur im Browser sichtbar sein. Er muss in der iOS App erscheinen. Er muss auf der Apple Watch als kurze Notifikation aufpoppen. Er muss vom Smart Speaker (Alexa) vorgelesen werden. Und er muss im VR-Headset (Vision Pro) als schwebendes Info-Panel dargestellt werden.

Das alte WordPress-Modell ("HTML First") scheitert hier, weil HTML an visuelle Darstellung gekoppelt ist. Die Lösung ist API-First Design. Wir definieren zuerst die Datenstruktur (JSON), und erst danach bauen wir die Benutzeroberflächen.

Featured Snippet: API-First Design ist ein Entwicklungsansatz, bei dem die Programmierschnittstelle (API) als das primäre Produkt betrachtet wird. Bevor eine Zeile Frontend-Code (Website, App) geschrieben wird, wird die Datenstruktur (Schema) definiert. Dies ermöglicht Omnichannel-Publishing (ein Inhalt, alle Kanäle), paralleles Arbeiten von Frontend- und Backend-Teams und eine massive Skalierbarkeit für zukünftige Geräte (IoT).

---

The Cost of Inaction: Das "Silo-Problem"

Unternehmen ohne API-Strategie haben "Content Silos".

• Die Marketing-Texte liegen fest im CMS der Website.
• Die Produkt-Infos liegen fest in der App-Datenbank.
• Die Support-FAQs liegen in Zendesk.

Wenn Sie nun den Text "Unsere Öffnungszeiten" ändern wollen, müssen Sie das an 3 Orten tun. Das ist teuer, fehleranfällig und langsam. Mit API-First liegt der Content an einem Ort (Single Source of Truth) und wird per API an alle Kanäle verteilt. Sie ändern es einmal, es ändert sich überall.

---

Das Prinzip: Content as Data (JSON)

Im API-First Ansatz ist Ihr Artikel kein "HTML-Dokument". Er ist ein Datensatz.

HTML Ansatz (Alt):

<h1>Der Audi e-tron</h1>
<p>Ein tolles Auto mit <span style="color:red">400km</span> Reichweite.</p>

Problem: Die Alexa kann mit <span style="color:red"> nichts anfangen.

API Ansatz (Neu, JSON):

{
  "product": "Audi e-tron",
  "range_km": 400,
  "description": "Ein tolles Auto...",
  "mood": "exciting"
}

Vorteil:

• Die Website macht daraus eine rote Überschrift.
• Die Alexa liest vor: "Reichweite: 400 Kilometer."
• Die Smartwatch zeigt nur ein Icon und "400km".

Wir trennen Inhalt von Präsentation. Das ist der Kern von Headless.

---

Strategie: REST vs. GraphQL

Wie holen wir die Daten?

REST (Der Klassiker)

• Sie rufen /api/products/123 auf.
• Sie bekommen alles zurück (Name, Preis, Beschreibung, Lagerbestand, Historie...).
• Nachteil: "Over-Fetching". Auf der Smartwatch brauchen Sie nur den Preis, laden aber 5MB Daten. Das kostet Akku.

GraphQL (Der Moderne)

• Sie fragen genau das ab, was Sie brauchen:

  query {
    product(id: "123") {
      price
    }
  }
  

• Sie bekommen nur den Preis.
• Vorteil: Perfekt für mobile Geräte mit schlechtem Netz. 2026 ist GraphQL der Standard für Headless CMS.

---

Myth-Busting: "APIs sind nur für Entwickler"

Falsch. APIs sind ein Business-Asset. Wenn Ihre Daten sauber per API verfügbar sind, können Sie Partnerschaften schließen.

• Beispiel: Ein Reiseblog hat eine API für seine "Top 10 Hotels".
• Eine Buchungs-App kann diese API nutzen, um die Hotels direkt anzuzeigen.
• Sie verdienen Geld (Affiliate), ohne dass der User Ihre Seite besuchen muss. Das nennt man "Platform Economy". Ihre Daten arbeiten für Sie, woanders.

---

Unasked Question: "Wie dokumentiere ich das?"

Eine API ohne Dokumentation ist wertlos. Der Standard 2026 ist OpenAPI (Swagger). Das ist eine maschinenlesbare Beschreibung Ihrer API. Tools können daraus automatisch schöne Dokumentationen generieren ("Developer Portal"). Wenn Sie API-First bauen, gehört die openapi.yaml Datei zum wichtigsten Asset Ihres Projekts.

---

FAQ: API-First