🟡 Wie dataCycle denkt

Bevor du mit konkreten API-Requests, Filtern oder Parametern arbeitest, ist es wichtig zu verstehen, wie dataCycle Daten grundsätzlich modelliert, organisiert und bereitstellt.

Viele Konzepte der API ergeben sich direkt aus diesen Grundprinzipien. Wenn du sie einmal verstanden hast, wirken Endpoints, Includes und Filter logisch statt komplex.

Zentrale Idee

dataCycle ist kein klassisches CMS und auch keine einfache Datenschnittstelle.

Statt Inhalte für einen bestimmten Ausgabekanal zu modellieren, verfolgt dataCycle einen anderen Ansatz:

Daten werden einmal strukturiert – und anschließend überall genutzt.

Die API ist dabei nicht der Ort, an dem Daten „zusammengebaut“ werden, sondern der Ort, an dem sauber strukturierte Daten kontrolliert ausgespielt werden.

Trennung von Datenmodell und Darstellung

Ein zentrales Designprinzip von dataCycle ist die konsequente Trennung von:

Datenstruktur (Was ist ein Inhalt?)
Datenpflege (Wie wird er erstellt, angereichert und geprüft?)
Datennutzung (Wie wird er ausgegeben?)

Die API kennt keine Webseiten, Apps oder Karten. Sie liefert ausschließlich strukturierte Inhalte.

Was du daraus machst – Website, App, Widget, Karte oder KI-Anwendung – entscheidet sich außerhalb von dataCycle.

Inhalte statt Seiten

In dataCycle existieren keine „Seiten“.

Stattdessen gibt es Inhalte (Things), zum Beispiel:

Veranstaltungen
Orte / POIs
Touren
Produkte
Medien
Schutzgebiete

Diese Inhalte sind:

eindeutig identifizierbar
strukturiert aufgebaut
untereinander verknüpfbar
unabhängig vom Ausgabekanal

Ein Inhalt kann gleichzeitig auf einer Website, in einer App, in einer Karte und über eine API genutzt werden – ohne dupliziert oder neu modelliert zu werden.

Endpoints als kontrollierte Sicht auf Daten

Die API stellt keine Rohdatenbank dar.

Stattdessen werden Inhalte über Endpoints bereitgestellt. Ein Endpoint ist eine vordefinierte Datensammlung, die festlegt:

welche Inhaltstypen enthalten sind
welche Filter- und Sortierlogiken gelten
wer Zugriff hat

Wenn ein Inhalt nicht in einem Endpoint liegt, kann ihn die API nicht liefern.

Endpoints sind damit das zentrale Steuerungsinstrument für:

Sicherheit
Performance
fachliche Kontrolle

Mehr dazu im nächsten Kapitel „Endpoints verstehen“.

Verknüpfungen sind explizit, nicht implizit

In dataCycle werden Inhalte nicht automatisch mit allem verknüpft, was existiert.

Beziehungen (z. B. „diese Tour gehört zu diesem Ort“) sind:

explizit modelliert
technisch nachvollziehbar
gezielt abrufbar

Die API liefert verknüpfte Inhalte nur dann, wenn du sie explizit anforderst (z. B. über include).

Das sorgt für:

klare Kontrolle über Payload-Größe
vorhersehbare Responses
bessere Performance

Filter statt Spezial-Endpunkte

dataCycle verfolgt bewusst keinen Ansatz mit unzähligen Spezial-Endpunkten.

Stattdessen gilt:

ein stabiler Endpoint
viele kombinierbare Filter

Du filterst Inhalte nach:

Text
Klassifizierungen
Attributen
Zeit
Geodaten

Dieses Prinzip macht die API:

flexibel
erweiterbar
langfristig stabil

Stabilität vor Bequemlichkeit

Die API von dataCycle ist darauf ausgelegt, über Jahre stabil zu bleiben.

Das bedeutet:

keine versteckten Logiken
keine kontextabhängigen Sonderfälle
keine „magischen“ Felder

Was du abfragst, bekommst du. Was du nicht abfragst, bleibt draußen.

Das ist manchmal etwas ausführlicher – aber dafür vorhersehbar, wartbar und integrationsfreundlich.

Kurz zusammengefasst

dataCycle denkt in:

Inhalten statt Seiten
Strukturen statt Layouts
Endpoints statt Direktzugriff
Filtern statt Spezial-URLs
Expliziten Verknüpfungen statt impliziter Magie

Wenn du dieses Denkmodell verinnerlichst, fühlen sich alle weiteren Kapitel der API-Dokumentation deutlich natürlicher an.

➡️ Im nächsten Schritt schauen wir uns an, wie Endpoints funktionieren und warum sie das Herzstück der API sind.