Was ist der Unterschied Zwischen Manifest, Report und Finding? Was Bedeuten Datenhierarchie-Begriffe in der Softwarearchitektur? Warum Wird API-Design Schichtenweise Aufgebaut? Wie Unterscheiden Sich Metadata, Artifact und Payload!

Sun, 02 Aug 2026 15:08:41 +0800

Stoßen Sie beim Lesen von API-Dokumentationen, Sicherheitsscan-Ergebnissen oder CI/CD-Pipeline-Logs häufig auf Begriffe wie Manifest, Report, Finding und Evidence? Dies sind keine Syntaxen einer bestimmten Programmiersprache, sondern branchenübliche Begriffe für Datenhierarchien. Was bedeuten diese Begriffe eigentlich genau?

Kernkonzept: Datenhierarchie Durch Einen “Gesundheitscheck” Verstehen

Wir können uns diese Begriffe wie den Ablauf einer medizinischen Untersuchung im Krankenhaus vorstellen. Diese vier Begriffe entsprechen genau den Datenebenen von High-Level-Zusammenfassungen bis hin zu Rohdaten auf der untersten Ebene.

Begriff	Analogie zur Medizinischen Untersuchung	Entsprechende Erklärung in der Softwarearchitektur
`Manifest`	Anmeldebogen der Untersuchung	Deklariert auszuführende Elemente, Versionen und Umgebungskonfigurationen; beschreibende Daten.
`Report`	Vollständiger Untersuchungsbericht	Vollständige Zusammenfassung nach Ausführung, einschließlich Gesamtstatus und Auditergebnissen.
`Finding`	Rote Anmerkung im Bericht	Konkreter im Bericht markierter Befund, z. B. “Bluthochdruck festgestellt” oder Sicherheitslücke.
`Evidence`	Datenstreifen des Blutdruckmessgeräts	Objektiver Rohbeleg, der den Befund stützt, wie Log-Einträge oder Messwerte.

Diese Begriffe sind keine reservierten Schlüsselwörter einer Programmiersprache, sondern branchenweit gemeinsame Datenmodelle.

Wir können ein Mermaid-Diagramm verwenden, um die Datenfluss- und Enthaltensein-Beziehungen zwischen diesen vier Konzepten darzustellen:

  graph TD
    A["Manifest (Ausführungsspezifikation/Metadaten)"] -->|Definiert Umfang & Ausführung| B["Report (Vollständiger Zusammenfassungsbericht)"]
    B -->|Enthält mehrere| C["Finding (Konkreter Befund/Beobachtung)"]
    C -->|Verknüpft mehrere| D["Evidence (Objektiver Rohbeleg)"]

Warum Ein Schichten-Design? Die 3 Großen Vorteile der Datenhierarchie

Warum werden Daten so detailliert aufgeteilt, anstatt alles in ein riesiges JSON-Objekt zu packen? Dieses Design bietet mehrere entscheidende Vorteile:

Ein hervorragendes API-Architekturdesign sorgt für reibungsloseres Frontend-Laden und erhöht die Datenverlässlichkeit sowie Erweiterbarkeit.

Vorteil	Erklärung
Trennung der Zuständigkeiten (Separation of Concerns)	Das Frontend kann zuerst die `Finding`-Übersicht für eine schnelle Anzeige laden und die schweren `Evidence`-Daten erst bei Bedarf abrufen.
Hohe Glaubwürdigkeit	Das Bereitstellen von `Evidence` beweist, dass ein `Finding` kein Fehlalarm ist, was die Prüfbarkeit des Systems erheblich steigert.
Flexible Erweiterbarkeit	Ein einzelnes `Finding` kann flexibel mit mehreren `Evidence`-Einträgen verknüpft werden, ohne das ursprüngliche Datenformat zu beschädigen.

Weitere Häufige Begriffe Zur Ergänzung: Metadata, Artifact und Payload

Neben den vier Kernschichten begegnen Ihnen beim Design von APIs, beim Aufsetzen von Pipelines oder Definieren von Übertragungsformaten häufig diese drei Begriffe: Metadata, Artifact und Payload:

Begriff	Kerndefinition	Alltagskontext-Analogie	Praktisches Anwendungsbeispiel in der Softwarearchitektur
`Metadata`	Daten, die die Daten selbst beschreiben	Versandetikett auf einem Paket, Foto-EXIF-Daten	`HTTP Header`, Anforderungs-Zeitstempel `timestamp`, Paginierung `page`.
`Artifact`	Physisch greifbares Ergebnis nach einem Prozess	Im Werk produziertes Auto, Untersuchungs-CD	Kompilierte `.apk`-Datei, `Docker Image`, Audit-`PDF`-Bericht.
`Payload`	Der eigentliche Kerninhalt der Geschäftsdaten	Das Smartphone im Inneren des Paketkartons	`JSON`-Geschäftsinhalt innerhalb des `HTTP POST Body`.

Payload ist wie der Inhalt im Paketkarton, während Metadata das außen angebrachte Versandetikett ist.

Um das Zusammenspiel dieser drei Begriffe besser zu verstehen, betrachten wir eine typische API Request-Datenstruktur:

{
  "metadata": {
    "version": "v1.2.0",
    "timestamp": "2026-08-02T15:08:41Z",
    "request_id": "req-98765"
  },
  "payload": {
    "report_id": "REP-2026-001",
    "status": "COMPLETED",
    "artifact_url": "https://example.com/artifacts/build-report.pdf"
  }
}

In diesem JSON-Beispiel:

metadata liefert den Übertragungs- und Umgebungskontext (Version, Zeitstempel, Anforderungs-ID).
payload enthält die eigentlichen Geschäftslogik-Daten (Berichts-ID, Status).
artifact_url verweist auf die tatsächlich durch den Build-Task erzeugte physische Datei (Artifact).

Die Macht Eines Gemeinsamen Vokabulars: Brücke Zur Systemübergreifenden Kommunikation

Wenn verschiedene Tools und Teams dasselbe Datenmodell übernehmen (z. B. Report -> Findings -> Evidence), sinkt der Kommunikationsaufwand zwischen Teams drastisch.

Stellen Sie sich vor, dass der von Ihrem CI/CD-Tool generierte Report direkt und nahtlos an das Sicherheitssystem zur Analyse übertragen werden kann – das ist die Integrationskraft einer gemeinsamen Domänensprache.

  sequenceDiagram
    autonumber
    actor CI as CI/CD Pipeline
    participant Scanner as Sicherheitsscanner
    participant Dashboard as Management-Dashboard
    
    CI->>Scanner: Übermittelt Manifest zur Ausführung des Scans
    Scanner->>Scanner: Generiert Report und Findings
    Scanner->>Dashboard: Sendet strukturierten Payload (Finding + Evidence)
    Dashboard-->>CI: Zeigt Auditergebnisse an

Zusammenfassung

Letztendlich dienen diese Begriffe dazu, Probleme der Datenkommunikation und Strukturierung zwischen Großsystemen zu lösen.