Content

Content é um registro de dados real moldado a partir de um Content Type (o gabarito). Tomando uma loja de roupas como exemplo, o Content Type "Produto" define a composição de itens como nome do produto, preço e descrição detalhada, e um "스테인리스 텀블러 500ml" é um Content que segue esse gabarito.

Content é composto por duas partes. fields contém os valores reais de cada campo, e sys contém estados como publicação, versão e arquivamento. Na CMA, Content é um recurso filho de Space, e os caminhos de consulta e exclusão têm como base /spaces/{spaceId}/contents, enquanto os caminhos de criação e modificação têm como base /spaces/{spaceId}/content-types/{contentTypeId}/contents, sob o Content Type. As operações de gestão são realizadas na CMA, e o snapshot publicado é entregue pela CDA.

Estrutura do recurso

A seguir está a resposta de uma consulta individual do Content publicado "스테인리스 텀블러 500ml". Junto com sys (propriedades de sistema), ele possui fields (valores dos campos) e metadata (informações adicionais como 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": [] }
}

Chaves principais:

• sys.id: identificador único do Content. Entra no {contentId} dos caminhos de consulta individual, modificação, exclusão e publicação.
• sys.contentType: o Refer que aponta para o Content Type que este Content segue.
• fields: os valores de cada campo. A chave é o apiName do campo, e o valor é um mapa por Locale. Explicado abaixo em A chave de fields é o apiName.
• metadata.tags: a lista de Tag aplicadas a este Content. Cada item tem o formato Refer<Tag>, e quando não há tags é um array vazio [].

A chave de fields é o apiName

A chave do objeto fields é o apiName de cada campo. Não é o id interno do Content Type nem o nome do campo exibido no estúdio de conteúdo (por exemplo, Nome do produto). Por isso, ao criar ou ler um Content, você deve usar como chave o apiName definido no Content Type.

O mapeamento entre os campos do Content Type "Produto" de demonstração e seu apiName é o seguinte.

O valor de cada campo é um mapa por Locale. O formato do valor depende de localized.

• Um campo localized: true pode ter valores em vários Locale, no formato { "<locale>": valor }. Por exemplo: "productName": { "en-US": "Stainless Tumbler 500ml", "ko-KR": "스테인리스 텀블러 500ml" }.
• Um campo localized: false (campo não dependente) recebe um valor apenas sob a chave do Locale padrão do Space. Nenhuma outra chave de Locale é permitida. Como o Locale padrão do Space de demonstração é en-US, o preço tem apenas a chave en-US, como em "price": { "en-US": 18000 }.

Qual é o Locale padrão, até qual Locale um campo required deve ser preenchido e a regra de fallback quando não há valor são tratados em Multilíngue (conceito).

Formato do valor por tipo

O formato do valor que entra dentro da chave de Locale segue o type do campo. A maioria dos tipos recebe diretamente o valor daquele tipo (os tipos de texto recebem uma string, Number e Long recebem um número, Boolean recebe true/false). Os tipos cujo formato é um objeto ou array e por isso geram mais confusão são os seguintes.

• Location: é um objeto { "latitude": <número>, "longitude": <número> }. O latitude fica entre -90 e 90, o longitude fica entre -180 e 180, e as duas chaves são obrigatórias. Como não aceita nenhuma chave além das definidas, usar chaves abreviadas como lat, lng ou lon resulta em rejeição.
• Refer: o valor é um objeto Refer que aponta para o alvo; em vez de colocar apenas a string do id, coloca-se diretamente o objeto sys. Quando aponta para outro Content, o targetType é Content; quando aponta para um Media, é Media. O formato do próprio Refer é definido em Formato do Refer nas propriedades de sistema (sys).
• Array: é um array JSON que contém os valores do tipo de elemento. Se o elemento for texto, é um array de strings; se o elemento for Refer (Content ou Media), é um array de objetos Refer. Não é um array de strings de id.

A seguir está um exemplo dos valores que entram dentro de fields (quando o Locale padrão do Space é en-US).

{
  "location": { "en-US": { "latitude": 37.5662, "longitude": 126.9910 } },
  "tags": { "en-US": ["novidade", "edição limitada"] },
  "photo": { "en-US": { "sys": { "type": "Refer", "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP", "targetType": "Media" } } },
  "photos": { "en-US": [ { "sys": { "type": "Refer", "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP", "targetType": "Media" } } ] }
}

Propriedades de sistema (sys)

Todo Content guarda as propriedades de sistema comuns no objeto sys. space, contentType, createdBy e updatedBy entram no formato Refer ({ "sys": { "id", "type": "Refer", "targetType" } }).

status é um dos 4 valores a seguir.

O objeto publish é um ponteiro que aponta para o estado de publicação. Quando publicado, possui todas as chaves a seguir.

Ao anular a publicação, version, at e by saem do publish, restando apenas firstAt e counter. Se nunca houve publicação, publish é { "counter": 0 }.

O objeto archive existe apenas quando arquivado. Quando arquivado, possui version (o sys.version no momento do arquivamento), at (momento do arquivamento) e by (o usuário que arquivou); quando não está arquivado, a própria chave archive não está presente.

O sys.version e todos os valores de momento no exemplo abaixo são os valores no momento real da chamada, e variam a cada chamada.

Publicação, versão e concorrência

O ciclo de vida do Content é o seguinte.

• Ao criar, status é Draft. O Content não é publicado automaticamente na criação. Esse ponto difere do Content Type. O Content Type é publicado automaticamente no momento da criação, mas o Content só entra no caminho de entrega após uma chamada de publicação separada.
• Ao publicar, status passa a Published.
• Ao modificar depois de publicar, status passa a Changed. Significa que há alterações não publicadas.
• Ao anular a publicação, status volta a Draft.
• Para arquivar, é preciso anular a publicação primeiro. Um Content em estado publicado não pode ser arquivado diretamente.

O sys.version sobe 1 a cada alteração.

As requisições de modificação, modificação parcial, publicação, anulação de publicação, arquivamento e desarquivamento devem enviar o sys.version atual no cabeçalho x-weegloo-version. Se esse valor estiver ausente ou divergir da versão atual, é considerado um conflito de modificação concorrente e a requisição é rejeitada. As requisições de criação e exclusão não têm esse cabeçalho. As transições de estado como publicação, anulação de publicação, arquivamento e desarquivamento não têm corpo de requisição separado.

API

A URL base de todos os endpoints abaixo é https://cma.weegloo.com/v1, e é necessário um token Bearer que autentique na CMA no cabeçalho Authorization. As operações de modificação, modificação parcial, publicação, anulação de publicação, arquivamento e desarquivamento devem enviar junto o cabeçalho X-Weegloo-Version (o sys.version atual do recurso) para o controle de concorrência otimista.

Ao filtrar ou ordenar a lista plana (GET /spaces/{spaceId}/contents) por fields.*, você deve indicar também o Content Type com sys.contentType.sys.id={contentTypeId}. A forma contentType={contentTypeId} não o substitui. O caminho /content-types/{contentTypeId}/contents já tem o Content Type explícito no caminho, portanto não é preciso indicá-lo separadamente.

Documentos relacionados

• Content Type: o gabarito deste Content (definição de campos, apiName).
• CDA Content: entrega o Content publicado aos visitantes (leitura).
• Tag: rótulo de classificação aplicado em metadata.tags.
• Multilíngue (conceito): Locale padrão, preenchimento obrigatório, fallback.