Media

Media ist die Ressource, die hochgeladene Dateien aufnimmt. Jede einzelne Datei wie ein Bild oder ein Dokument wird als ein Media-Eintrag verwaltet. Am Beispiel eines Modegeschäft-Shops ist das Produktfoto "Edelstahl-Thermobecher 500 ml Seitenansicht" ein Media-Eintrag.

Media wird getrennt von Content verwaltet. Content verweist über ein Feld vom Typ Refer (zum Beispiel das "Hauptfoto" eines Produkts) auf Media und verwendet so dessen Datei. In der CMA ist Media eine untergeordnete Ressource des Space, und der Pfad basiert auf /spaces/{spaceId}/medias. Verwaltungsvorgänge werden in der CMA ausgeführt, und veröffentlichte Media werden über eine Auslieferungs-URL extern zugänglich gemacht.

Ressourcenstruktur

Im Folgenden steht die Antwort auf eine Einzelabfrage des veröffentlichten Media "Edelstahl-Thermobecher 500 ml Seitenansicht". Neben sys (Systemeigenschaften) enthält es fields (Feldwerte) und metadata (Zusatzinformationen wie Tags).

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7PV9MlFUzv3r",
    "type": "Media",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "publish": {
      "version": 1,
      "at": "2026-06-18T10:11:46.712Z",
      "firstAt": "2026-06-18T10:11:46.712Z",
      "counter": 1,
      "by": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } }
    },
    "createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-18T10:11:46.586Z",
    "updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-18T10:11:46.712Z",
    "version": 2,
    "status": "Published"
  },
  "fields": {
    "title": { "ko-KR": "스테인리스 텀블러 500ml 측면 컷" },
    "description": { "ko-KR": "흰 배경에서 찍은 텀블러 측면 제품 사진입니다." },
    "file": {
      "ko-KR": {
        "fileName": "tumbler.png",
        "contentType": "image/png",
        "mimeGroups": ["Image"],
        "url": "https://weegloo-media.com/medias/HnQ32YiH/v3r/3trmXRM3RqbgSnifyg7PV9MlFUzv3r/ko-KR/1/tumbler.png",
        "detail": { "size": 50847, "image": { "width": 900, "height": 900 } }
      }
    }
  },
  "metadata": { "tags": [] }
}

Wichtige Schlüssel:

• sys.id: Der eindeutige Bezeichner des Media. Er wird im {mediaId} der Pfade für Einzelabfrage, Änderung, Löschung und Veröffentlichung eingesetzt.
• fields: Die Feldwerte des Media. Es besteht aus den drei Teilen title, description und file; die genaue Form wird unten unter Dateistruktur (file) erläutert.
• metadata.tags: Die Liste der Tag, die an diesem Media angebracht sind. Jeder Eintrag hat die Form Refer<Tag>; gibt es keine Tags, ist es ein leeres Array [].

Anders als Content hat Media kein contentType. Ohne ein Schema, das die Feldzusammensetzung festlegt, hat jedes Media dieselbe Struktur aus title, description und file.

Dateistruktur (file)

fields besteht aus den drei Teilen title, description und file, die jeweils eine Map pro Locale sind. title und description ordnen einem Locale-Schlüssel einen Zeichenkettenwert zu, und file ordnet einem Locale-Schlüssel ein Dateiobjekt zu. Wie im obigen Beispiel hat das Demo-Media unter dem einen Schlüssel ko-KR einen Wert.

Das file-Objekt eines fertig veröffentlichten Media hat die folgenden Schlüssel.

mimeGroups ist der Wert, der die Datei nach logischer Klassifizierung bündelt. Es enthält einen oder mehrere der folgenden Werte.

Attachment, Plaintext, Image, Audio, Video, RichText, Presentation, Spreadsheet, PdfDocument, Archive, Code, Markup.

Form des file-Objekts während der Verarbeitung

Eine hochgeladene Datei wird nicht unmittelbar nach dem Erstellen des Media sofort ausgeliefert. Während das System die Datei verarbeitet, kommen am file-Objekt zwei weitere Schlüssel hinzu.

• upload: Ein Refer<Upload>, der auf das zu verarbeitende Upload verweist.
• state: Der Verarbeitungsstatus. Einer der folgenden Werte.

Nach Abschluss der Verarbeitung entfallen upload und state, und stattdessen werden url und detail gefüllt. Das heißt: Fehlt der Schlüssel state und ist url vorhanden, ist diese Datei auslieferbar.

Systemeigenschaften (sys)

Jedes Media enthält die gemeinsamen Systemeigenschaften im Objekt sys. space, createdBy und updatedBy haben die Form Refer ({ "sys": { "id", "type": "Refer", "targetType" } }).

Anders als Content hat Media keine Eigenschaft contentType. Das liegt daran, dass es keinem Schema folgt.

status ist einer der folgenden vier Werte.

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

Beim Zurücknehmen der Veröffentlichung entfallen version, at und by aus publish, und nur firstAt und counter bleiben übrig. 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 (der sys.version zum Zeitpunkt der Archivierung), at (Zeitpunkt der Archivierung) und by (Benutzer, der archiviert hat); ist es nicht archiviert, fehlt der Schlüssel archive selbst.

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

Upload- und Veröffentlichungs-Lebenszyklus

Ein Media wird erstellt, indem zuerst die Datei hochgeladen und anschließend das Ergebnis referenziert wird.

1. Laden Sie über die Upload API eine Datei hoch und erhalten Sie ein Upload.
2. Erstellen Sie mit POST /medias ein Media, das auf dieses Upload verweist. Unmittelbar nach der Erstellung ist status gleich Draft, und der state von file ist PENDING.
3. Sobald das System die Dateiverarbeitung abgeschlossen hat, setzt es das Media automatisch auf Published. Zu diesem Zeitpunkt wird die Datei auslieferbar.

Geben Sie bei der POST-Anfrage den Header X-Weegloo-Ignore-Publish: true an, wird die automatische Veröffentlichung übersprungen und es bleibt im Zustand Draft. Auch bei Änderung und Teiländerung wird standardmäßig nach Abschluss der Verarbeitung automatisch erneut veröffentlicht, was sich mit demselben Header ausschalten lässt.

Bei Anfragen zu Änderung, Teiländerung, Veröffentlichung, Zurücknahme der Veröffentlichung, Archivierung und Aufhebung der Archivierung muss im Header x-weegloo-version der aktuelle sys.version mitgegeben werden. Fehlt dieser Wert oder weicht er von der aktuellen Version ab, wird dies als gleichzeitiger Änderungskonflikt gewertet und die Anfrage abgelehnt. Anfragen zu Erstellung und Löschung haben diesen Header nicht. Statusübergänge wie Veröffentlichung, Zurücknahme der Veröffentlichung, Archivierung und Aufhebung der Archivierung haben keinen eigenen Anfragetext.

Archivierung und Löschung sind im veröffentlichten Zustand nicht direkt möglich. Zuerst muss die Veröffentlichung zurückgenommen werden. Der Versuch, ein veröffentlichtes Media zu archivieren, wird mit WGL422007 abgelehnt, der Versuch, es zu löschen, mit WGL422009.

API

Die Basis-URL aller folgenden Endpunkte ist https://cma.weegloo.com/v1, und im Header Authorization ist ein Bearer-Token erforderlich, der sich gegenüber der CMA authentifiziert. Bei Änderung, Teiländerung, Veröffentlichung, Zurücknahme der Veröffentlichung, Archivierung und Aufhebung der Archivierung muss zur optimistischen Nebenläufigkeitskontrolle zusätzlich der Header X-Weegloo-Version (der sys.version der aktuellen Ressource) mitgesendet werden.

Verwandte Dokumente

• Upload API: Anfrage, um eine Datei hochzuladen und ein Upload zu erhalten, das für die Erstellung von Media verwendet wird.
• Content: Inhaltsdaten, die über ein Refer-Feld auf Media verweisen und es verwenden.
• Tag: Klassifizierungslabel, das an metadata.tags angebracht wird.