Content

Content ist ein einzelner konkreter Datensatz, der mit einem Content Type (der Vorlage) erzeugt wird. Am Beispiel eines Bekleidungs-Onlineshops: Der Content Type "Produkt" legt den Aufbau der Angaben wie Produktname, Preis und ausführliche Beschreibung fest, und "스테인리스 텀블러 500ml" ist ein einzelner Content, der dieser Vorlage folgt.

Content besteht aus zwei Teilen. In fields stehen die tatsächlichen Werte der einzelnen Felder, in sys der Zustand wie Veröffentlichung, Version und Archivierung. In der CMA ist Content eine Unterressource von Space: Für Abruf und Löschen dient der Pfad /spaces/{spaceId}/contents, für Erstellung und Änderung der unter Content Type liegende Pfad /spaces/{spaceId}/content-types/{contentTypeId}/contents. Verwaltungsvorgänge werden in der CMA ausgeführt, und der veröffentlichte Snapshot wird über die CDA ausgeliefert.

Ressourcenstruktur

Im Folgenden steht die Antwort eines Einzelabrufs des veröffentlichten Content "스테인리스 텀블러 500ml". Neben sys (Systemattribute) enthält er fields (Feldwerte) und metadata (Zusatzinformationen wie Tags).

{
  "sys": {
    "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"
  },
  "fields": {
    "price": { "en-US": 18000 },
    "productName": { "en-US": "Stainless Tumbler 500ml", "ko-KR": "스테인리스 텀블러 500ml" }
  },
  "metadata": { "tags": [] }
}

Wichtige Schlüssel:

• sys.id: Eindeutige Kennung des Content. Sie wird im {contentId} der Pfade für Einzelabruf, Änderung, Löschung und Veröffentlichung eingesetzt.
• sys.contentType: Ein Refer, der auf den Content Type verweist, dem dieser Content folgt.
• fields: Die Werte der einzelnen Felder. Der Schlüssel ist der apiName des Felds, der Wert ist eine Zuordnung je Locale. Erläutert unter Der Feldschlüssel ist der apiName.
• metadata.tags: Liste der Tag, die an diesen Content gehängt sind. Jeder Eintrag hat die Form Refer<Tag>; sind keine Tags vergeben, ist es ein leeres Array [].

Der Feldschlüssel ist der apiName

Der Schlüssel des fields-Objekts ist der apiName des jeweiligen Felds. Es ist nicht die interne id des Content Type und nicht der im Content-Studio angezeigte Feldname (z. B. Produktname). Beim Erstellen oder Lesen eines Content muss daher der im Content Type definierte apiName als Schlüssel verwendet werden.

Die Felder des Demo-Content Type "Produkt" und ihre apiName-Zuordnung sind wie folgt.

Jeder Feldwert ist eine Zuordnung je Locale. Die Form des Werts hängt von localized ab.

• Ein Feld mit localized: true kann in der Form { "<locale>": Wert } Werte für mehrere Locales enthalten. Beispiel: "productName": { "en-US": "Stainless Tumbler 500ml", "ko-KR": "스테인리스 텀블러 500ml" }.
• Ein Feld mit localized: false (nicht lokalisiertes Feld) erhält nur einen Wert unter dem Schlüssel der Standard-Locale des Space. Andere Locale-Schlüssel sind nicht zulässig. Da die Standard-Locale des Demo-Space en-US ist, hat der Preis nur den einen Schlüssel en-US, etwa "price": { "en-US": 18000 }.

Welche Locale die Standard-Locale ist, bis zu welcher Locale ein required-Feld ausgefüllt werden muss und welche Fallback-Regeln gelten, wenn kein Wert vorhanden ist, wird unter Mehrsprachigkeit (Konzept) behandelt.

Wertform je Typ

Die Form des Werts innerhalb eines Locale-Schlüssels richtet sich nach dem type des Felds. Die meisten Typen nehmen den Wert dieses Typs unverändert auf (Texttypen einen String, Number und Long eine Zahl, Boolean true/false). Die Typen, deren Form ein Objekt oder ein Array ist und die deshalb leicht zu Verwechslungen führen, sind die folgenden.

• Location: ein Objekt der Form { "latitude": <Zahl>, "longitude": <Zahl> }. latitude liegt zwischen -90 und 90, longitude zwischen -180 und 180; beide Schlüssel sind erforderlich. Außer den definierten Schlüsseln werden keine weiteren akzeptiert, weshalb verkürzte Schlüssel wie lat, lng oder lon zurückgewiesen werden.
• Refer: ein Refer-Objekt, das auf das Ziel verweist; es wird nicht nur ein id-String, sondern das sys-Objekt unverändert eingesetzt. Verweist es auf einen anderen Content, ist targetType gleich Content, verweist es auf ein Media, gleich Media. Die Refer-Form selbst wird unter Die Refer-Form bei den Systemattributen (sys) definiert.
• Array: ein JSON-Array, das Werte des Elementtyps enthält. Sind die Elemente Text, ist es ein Array von Strings; sind die Elemente Refer (Content oder Media), ist es ein Array von Refer-Objekten. Es ist kein Array von id-Strings.

Im Folgenden stehen Beispiele für die Werte innerhalb von fields (wenn die Standard-Locale des Space en-US ist).

{
  "location": { "en-US": { "latitude": 37.5662, "longitude": 126.9910 } },
  "tags": { "en-US": ["Neuheit", "Limitierte Auflage"] },
  "photo": { "en-US": { "sys": { "type": "Refer", "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP", "targetType": "Media" } } },
  "photos": { "en-US": [ { "sys": { "type": "Refer", "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP", "targetType": "Media" } } ] }
}

Systemattribute (sys)

Jeder Content führt die gemeinsamen Systemattribute im sys-Objekt. space, contentType, createdBy und updatedBy haben die Refer-Form ({ "sys": { "id", "type": "Refer", "targetType" } }).

status ist einer der folgenden vier Werte.

Das publish-Objekt ist ein Zeiger auf den Veröffentlichungszustand. Im veröffentlichten Zustand enthält es alle folgenden Schlüssel.

Beim Zurückziehen entfallen aus publish die Schlüssel version, at und by, und es bleiben nur firstAt und counter. Wurde noch nie veröffentlicht, ist publish gleich { "counter": 0 }.

Das archive-Objekt existiert nur im archivierten Zustand. Im archivierten Zustand enthält es version (die sys.version zum Zeitpunkt der Archivierung), at (Archivierungszeitpunkt) und by (archivierende Person); ist die Ressource nicht archiviert, fehlt der Schlüssel archive vollständig.

Die sys.version und alle Zeitwerte im folgenden Beispiel sind die Werte zum tatsächlichen Aufrufzeitpunkt und unterscheiden sich von Aufruf zu Aufruf.

Veröffentlichung, Version und Nebenläufigkeit

Der Lebenszyklus eines Content ist wie folgt.

• Beim Erstellen ist status gleich Draft. Content wird beim Erstellen nicht automatisch veröffentlicht. Darin unterscheidet er sich vom Content Type. Ein Content Type wird mit der Erstellung automatisch veröffentlicht, ein Content gelangt jedoch erst durch einen separaten Veröffentlichungsaufruf in den Auslieferungsweg.
• Beim Veröffentlichen wird status zu Published.
• Wird nach der Veröffentlichung geändert, wird status zu Changed. Das bedeutet, dass nicht veröffentlichte Änderungen vorliegen.
• Beim Zurückziehen wird status wieder zu Draft.
• Zum Archivieren muss zuerst zurückgezogen werden. Ein veröffentlichter Content kann nicht direkt archiviert werden.

sys.version erhöht sich bei jeder Änderung um 1.

Bei Anfragen zum Ändern, Teiländern, Veröffentlichen, Zurückziehen, Archivieren und Dearchivieren muss die aktuelle sys.version im Header x-weegloo-version mitgesendet werden. Fehlt dieser Wert oder weicht er von der aktuellen Version ab, wird dies als Konflikt durch gleichzeitige Änderung gewertet und die Anfrage abgelehnt. Anfragen zum Erstellen und Löschen haben diesen Header nicht. Zustandsübergänge wie Veröffentlichen, Zurückziehen, Archivieren und Dearchivieren haben keinen eigenen Anfragetext.

API

Die Basis-URL aller folgenden Endpunkte ist https://cma.weegloo.com/v1, und im Header Authorization ist ein Bearer-Token erforderlich, das sich gegenüber der CMA authentifiziert. Beim Ändern, Teiländern, Veröffentlichen, Zurückziehen, Archivieren und Dearchivieren muss zur optimistischen Nebenläufigkeitskontrolle zusätzlich der Header X-Weegloo-Version (die aktuelle sys.version der Ressource) gesendet werden.

Wenn Sie die flache Liste (GET /spaces/{spaceId}/contents) nach fields.* filtern oder sortieren, müssen Sie sie zusätzlich mit sys.contentType.sys.id={contentTypeId} auf einen Content Type eingrenzen. Ein bloßes contentType={contentTypeId} ersetzt dies nicht. Der Pfad je Content Type (/content-types/{contentTypeId}/contents) trägt ihn bereits, sodass er dort nicht nötig ist.

Verwandte Dokumente

• Content Type: Die Vorlage dieses Content (Felddefinition, apiName).
• CDA Content: Auslieferung des veröffentlichten Content an Besucher (Lesen).
• Tag: Klassifizierungslabel, das an metadata.tags gehängt wird.
• Mehrsprachigkeit (Konzept): Standard-Locale, Pflichtfüllung, Fallback.