Propriedades de sistema (sys)

Toda resposta de recurso do WEEGLOO divide-se em duas partes. De um lado ficam os dados de conteúdo do recurso, como fields; do outro, os metadados gerenciados pelo sistema. Esses metadados ficam todos no objeto sys.

O sys contém o identificador do recurso (id), o tipo (type), os horários de criação e modificação, a versão e as relações com outros recursos. Esta página reúne em um só lugar a estrutura do sys comum a todos os recursos e as diferenças entre os tipos de recurso. As referências de cada recurso descrevem separadamente apenas as chaves de sys próprias daquele recurso e remetem a esta página para a parte comum.

Campos comuns

O sys de quase todos os recursos tem os campos a seguir. createdBy, updatedBy e space aparecem no formato Refer, que aponta para outro recurso ({ "sys": { "id", "type": "Refer", "targetType" } }). O formato detalhado é tratado em Formato Refer, mais abaixo.

O version também serve para evitar conflitos de modificação simultânea. As requisições da família de alterações, como modificar e publicar, devem enviar o valor atual de version no cabeçalho X-Weegloo-Version. As regras detalhadas estão em Convenções.

A Organization não é filha de um Space, portanto não tem space. Em vez disso, tem plan (Refer<Plan>), que aponta para o plano de assinatura ao qual pertence, e isOfficial (boolean), que indica se é oficial. O Space tem organization (Refer<Organization>), que aponta para a Organization superior, e plan.

Formato Refer

Dentro do sys, uma referência que aponta para outro recurso usa sempre o mesmo formato. O type é fixo como "Refer" e o targetType informa o tipo do recurso apontado.

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

O targetType recebe o nome do tipo do recurso apontado. Por exemplo, em space o targetType é "Space"; em createdBy e updatedBy é "User"; e em contentType de um Content é "ContentType". Ou seja, os tipos escritos como Refer<User> ou Refer<Space> têm todos este formato, mudando apenas o targetType.

Diferenças entre os tipos de recurso

Sobre os campos comuns somam-se propriedades adicionais conforme o tipo de recurso. Há três grupos principais.

Recursos com ciclo de vida de publicação (Content, Media)

Content e Media têm um ciclo de vida de redação, publicação e arquivamento. Por isso, ao sys somam-se propriedades que indicam o estado de publicação.

O status é um entre os 4 valores a seguir.

O objeto publish é um ponteiro que indica o estado de publicação. Quando está publicado, tem todas as chaves a seguir.

Ao despublicar, version, at e by saem de publish e restam apenas firstAt e counter. Se nunca foi publicado, publish é { "counter": 0 }.

O objeto archive existe apenas quando está arquivado e tem o version do momento do arquivamento, o horário de arquivamento at e o usuário que arquivou by. Quando não está arquivado, a própria chave archive não existe.

Aqui, sys.version é a versão de trabalho (sobe a cada alteração, como criar, modificar e publicar) e publish.version é a última versão publicada. As duas podem ser diferentes.

A seguir, um exemplo do sys de um Content publicado.

{
  "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"
}

A ordem das transições de estado do ciclo de vida de publicação e a resposta de cada etapa são tratadas em Content e Media.

Recursos de configuração (Tag, Locale, Organization, Space etc.)

Recursos como Tag, Locale, Organization, Space, SpaceRole, ServiceUserRole, Webhook e ServiceLogin não têm conceito de publicação. Quando criados, aplicam-se de imediato e não há etapa de publicação para colocá-los no caminho de entrega.

Portanto, o sys deles não tem status, publish nem archive; tem apenas version, junto com os campos comuns. O version sobe em 1 a cada modificação e é enviado no cabeçalho X-Weegloo-Version nas requisições de alteração.

O SpaceRole tem, além disso, isLocked (boolean). Se for true, significa que é uma função fornecida por padrão pelo WEEGLOO.

Recursos especiais (ServiceUser, WebHosting)

Alguns recursos têm um sys que não se encaixa nos dois grupos acima.

O ServiceUser é um recurso criado pelo cadastro de membros do produto. Como não é um recurso que uma pessoa cria e altera no estúdio de conteúdo, o sys não tem createdBy, updatedBy nem version. Em vez disso, tem o meio de login provider (string) e email (string). Como não há version, ao modificar um ServiceUser não é necessário o cabeçalho X-Weegloo-Version.

O WebHosting é um recurso que hospeda artefatos de implantação. Tem os campos comuns e version, e a isso soma-se o estado de processamento da implantação state (enum). Isto não é um estado de publicação, mas o estado de andamento do processamento do artefato de implantação enviado.

Diferença entre CMA e CDA: version vs revision

Mesmo para o mesmo Content ou Media, o formato do sys é diferente conforme a API de onde é recebido.

O Content e Media recebidos da CMA (gerenciamento) são recursos em trabalho. Por isso trazem version, status, publish (e archive, se arquivado), informando ao mesmo tempo o estado de trabalho atual e o estado de publicação.

A CDA (entrega) entrega apenas o snapshot publicado. Como não existe o conceito de estado de trabalho, o sys não traz version, status, publish nem archive. Em vez disso, usa um único revision (integer), que aponta o número do snapshot publicado. O revision recebe a versão daquele momento a cada publicação.

{
  "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
}

O modelo de entrega por publicação (só o que foi publicado é entregue, o snapshot de publicação e o revision) é tratado em detalhe em Visão geral da CDA.

Documentos relacionados

• Parâmetros de consulta comuns: consulta de listas e paginação.
• Convenções: tipo de mídia, JSON Patch e concorrência (X-Weegloo-Version).
• Erros: formato das respostas de erro e códigos comuns.
• Visão geral da CDA: modelo de entrega de snapshot de publicação (revision).