Systemeigenschaften (sys)

Jede Ressourcenantwort von WEEGLOO teilt sich in zwei Stränge. Auf der einen Seite stehen die eigentlichen Inhaltsdaten der Ressource wie fields, auf der anderen Seite die vom System verwalteten Metadaten. Diese Metadaten sind sämtlich im Objekt sys enthalten.

sys umfasst den Bezeichner der Ressource (id), ihre Art (type), Erstellungs- und Änderungszeitpunkt, Version sowie die Beziehungen zu anderen Ressourcen. Diese Seite fasst an einer Stelle die Struktur von sys, die alle Ressourcen gemeinsam haben, sowie die Unterschiede je nach Ressourcenart zusammen. Die einzelnen Ressourcenreferenzen beschreiben jeweils nur die für die betreffende Ressource spezifischen sys-Schlüssel und verweisen für den gemeinsamen Teil auf diese Seite.

Gemeinsame Felder

Das sys nahezu jeder Ressource besitzt die folgenden Felder. createdBy, updatedBy und space werden in der Refer-Form ({ "sys": { "id", "type": "Refer", "targetType" } }) angegeben, die auf eine andere Ressource verweist. Die genaue Form wird weiter unten unter Refer-Form behandelt.

version dient auch dazu, Konflikte bei gleichzeitigen Änderungen zu verhindern. Bei ändernden Anfragen wie Änderung oder Veröffentlichung muss der aktuelle Wert von version im Header X-Weegloo-Version mitgesendet werden. Die genauen Regeln finden Sie unter Konventionen.

Eine Organization ist keiner Space untergeordnet und besitzt daher kein space. Stattdessen besitzt sie plan (Refer<Plan>), das auf den zugehörigen Tarif verweist, und isOfficial (boolean), das angibt, ob sie offiziell ist. Ein Space besitzt organization (Refer<Organization>), das auf die übergeordnete Organization verweist, sowie plan.

Refer-Form

Eine Referenz, die innerhalb von sys auf eine andere Ressource verweist, verwendet stets dieselbe Form. type ist fest auf "Refer" gesetzt, und targetType gibt die Art der referenzierten Ressource an.

{
  "sys": {
    "id": "HnQ32YiH",
    "type": "Refer",
    "targetType": "Space"
  }
}

In targetType steht der Name der Art der referenzierten Ressource. Beispielsweise hat space den targetType "Space", createdBy und updatedBy haben "User", und contentType eines Content hat "ContentType". Das heißt: Alle als Refer<User> oder Refer<Space> notierten Typen haben diese Form, lediglich targetType unterscheidet sich.

Unterschiede je nach Ressourcenart

Über die gemeinsamen Felder hinaus kommen je nach Ressourcenart weitere Eigenschaften hinzu. Diese teilen sich grob in drei Stränge.

Ressourcen mit Veröffentlichungslebenszyklus (Content, Media)

Content und Media besitzen einen Lebenszyklus aus Erstellen, Veröffentlichen und Archivieren. Daher kommen in sys Eigenschaften hinzu, die den Veröffentlichungsstatus darstellen.

status ist einer der folgenden vier Werte.

Das Objekt publish ist ein Zeiger auf den Veröffentlichungsstatus. Im veröffentlichten Zustand besitzt es alle folgenden Schlüssel.

Bei einer Veröffentlichungsrücknahme entfallen aus publish die Schlüssel version, at und by, und nur firstAt und counter bleiben erhalten. Wenn noch nie veröffentlicht wurde, lautet publish { "counter": 0 }.

Das Objekt archive ist nur während der Archivierung vorhanden und besitzt version zum Archivierungszeitpunkt, den Archivierungszeitpunkt at und die archivierende Benutzerin oder den archivierenden Benutzer by. Liegt kein Archivierungszustand vor, fehlt der Schlüssel archive vollständig.

Dabei ist sys.version die Arbeitsversion (steigt bei jeder Änderung wie Erstellen, Ändern oder Veröffentlichen), während publish.version die zuletzt veröffentlichte Version ist. Die beiden können sich unterscheiden.

Es folgt ein Beispiel für das sys eines veröffentlichten Content.

{
  "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP",
  "type": "Content",
  "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
  "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
  "publish": {
    "version": 1,
    "at": "2026-06-18T09:51:44.128Z",
    "firstAt": "2026-06-18T09:51:44.128Z",
    "counter": 1,
    "by": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } }
  },
  "createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
  "createdAt": "2026-06-18T09:51:14.597Z",
  "updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
  "updatedAt": "2026-06-18T09:51:44.128Z",
  "version": 2,
  "status": "Published"
}

Die Reihenfolge der Statusübergänge im Veröffentlichungslebenszyklus und die Antworten der einzelnen Stufen werden unter Content und Media behandelt.

Konfigurationsressourcen (Tag, Locale, Organization, Space usw.)

Ressourcen wie Tag, Locale, Organization, Space, SpaceRole, ServiceUserRole, Webhook und ServiceLogin kennen kein Veröffentlichungskonzept. Sobald sie erstellt sind, gelten sie unmittelbar, und es gibt keinen Schritt, der sie durch Veröffentlichung in den Auslieferungspfad bringt.

Daher besitzt deren sys weder status, publish noch archive, sondern neben den gemeinsamen Feldern nur version. version steigt bei jeder Änderung um 1 und wird bei ändernden Anfragen im Header X-Weegloo-Version mitgesendet.

Eine SpaceRole besitzt darüber hinaus isLocked (boolean). true bedeutet, dass es sich um eine von WEEGLOO standardmäßig bereitgestellte Rolle handelt.

Sonderressourcen (ServiceUser, WebHosting)

Einige Ressourcen besitzen ein sys, das nicht in die beiden obigen Stränge passt.

Ein ServiceUser ist eine Ressource, die durch die Registrierung im Produkt entsteht. Da es sich nicht um eine Ressource handelt, die ein Mensch im Content-Studio erstellt und ändert, besitzt das sys weder createdBy, updatedBy noch version. Stattdessen besitzt es das Anmeldemittel provider (string) und email (string). Da kein version vorhanden ist, wird beim Ändern eines ServiceUser kein Header X-Weegloo-Version benötigt.

Ein WebHosting ist eine Ressource, die das Deployment hostet. Es besitzt die gemeinsamen Felder und version, ergänzt um den Verarbeitungsstatus des Deployments state (enum). Dies ist kein Veröffentlichungsstatus, sondern der Fortschrittsstatus der Verarbeitung des hochgeladenen Deployments.

Unterschied zwischen CMA und CDA: version vs. revision

Selbst beim gleichen Content oder Media unterscheidet sich die Form von sys danach, über welche API es bezogen wird.

Ein Content oder Media, das man von der CMA (Verwaltung) bezieht, ist eine in Bearbeitung befindliche Ressource. Daher enthält es version, status, publish (und im Archivierungsfall archive) zusammen und teilt so sowohl den aktuellen Arbeitsstatus als auch den Veröffentlichungsstatus mit.

Die CDA (Auslieferung) liefert nur den veröffentlichten Snapshot aus. Da es kein Konzept eines Arbeitsstatus gibt, enthält sys weder version, status, publish noch archive. Stattdessen verwendet es ein einzelnes revision (integer), das auf die Nummer des veröffentlichten Snapshots verweist. In revision wird bei jeder Veröffentlichung die Version dieses Zeitpunkts abgelegt.

{
  "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP",
  "type": "Content",
  "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
  "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
  "createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
  "createdAt": "2026-06-18T09:51:14.597Z",
  "updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
  "updatedAt": "2026-06-18T09:51:44.128Z",
  "revision": 3
}

Das Auslieferungsmodell der Veröffentlichung (nur Veröffentlichtes wird ausgeliefert, Veröffentlichungs-Snapshot, revision) wird in der CDA-Übersicht ausführlich behandelt.

Verwandte Dokumente

• Gemeinsame Abfrageparameter: Listenabruf und Paginierung.
• Konventionen: Medientyp, JSON Patch, Nebenläufigkeit (X-Weegloo-Version).
• Fehler: Format der Fehlerantworten und gemeinsame Codes.
• CDA-Übersicht: Auslieferungsmodell des Veröffentlichungs-Snapshots (revision).