ACDA (App Content Delivery API)

Dernière mise à jour : 22 juin 2026

ACDA (App Content Delivery API) est une API en lecture seule qui livre les Content et Media publiés aux membres inscrits au produit, c'est-à-dire aux ServiceUser. Une fois que l'exploitant du Space a publié son contenu, les membres le lisent via ACDA. Considérez-la comme la version ServiceUser du rôle que CDA joue en livrant le contenu publié aux visiteurs publics, mais exercée sous l'identité d'un membre. ACDA ne comporte que des points d'accès de consultation (GET) ; la création, la modification et la suppression relèvent d'ACMA.

Les appels ACDA utilisent un jeton Bearer émis par ServiceLogin. Ce jeton n'est valable que sur ACMA et ACDA et ne peut pas être utilisé pour CMA ou CDA (pour le flux d'émission du jeton, voir l'API Auth).

Différences avec CDA

La forme des réponses ACDA est identique à celle de CDA. Seul un instantané des données publiées est livré (sys ne contient que revision, la version au moment de la publication, sans version, status ni publish), et la langue reçue lors de la consultation est déterminée par locale. Deux points distinguent ACDA de CDA : la portée de lecture et l'identité.

  • Portée de lecture par membre : avec CDA, quiconque appelle avec un même DeliveryAccessToken voit le même ensemble publié. ACDA ne renvoie que ce qui est autorisé pour le ServiceUser appelant ; ce qui est autorisé dépend du ServiceUserRole de ce membre et de ses affectations. L'identité diffère également. CDA s'appelle avec un DeliveryAccessToken, ACDA avec un jeton de membre émis par ServiceLogin.

La façon de déterminer la langue reçue via le paramètre de requête locale est elle aussi identique à CDA. Si vous donnez un code comme locale=ko-KR, fields est renvoyé avec une seule valeur pour cette locale (s'il n'y en a pas et que le Fallback n'aboutit pas non plus, la valeur est vide ou null) ; si vous l'omettez, le renvoi se fait de la même manière avec la Locale par défaut du Space ; et si vous donnez locale=*, une carte contenant les valeurs de toutes les locales est renvoyée telle quelle. Dans les deux premiers cas, où une seule langue est reçue, l'en-tête x-weegloo-locale indiquant la locale réellement utilisée est inclus (il ne l'est pas lorsque locale=*).

Structure de la ressource

Voici la forme sous laquelle ACDA livre l'un des Content « Produit » du Space de démonstration. C'est le résultat d'une consultation avec locale=ko-KR, où chaque valeur de fields contient une seule valeur de ko-KR.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7OGhwhlqvAvq",
    "type": "Content",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
    "createdAt": "2026-06-15T15:16:12.151Z",
    "updatedAt": "2026-06-16T14:35:11.210Z",
    "revision": 3
  },
  "fields": {
    "productName": "스테인리스 텀블러 500ml",
    "price": 18000,
    "description": "이중 진공 단열로 보온·보냉이 오래갑니다. 500ml 대용량."
  }
}

Clés principales :

  • sys.id : identifiant unique du Content. Il s'insère dans le {contentId} du chemin de consultation unitaire.
  • sys.type : type de ressource ; pour un Content, c'est toujours "Content".
  • sys.space : référence pointant vers le Space auquel appartient ce Content.
  • sys.contentType : référence pointant vers le Content Type que suit ce Content.
  • sys.revision : version au moment de la publication. À chaque publication, la version de ce moment-là y est consignée. ACDA ne contenant pas les version, status ni publish de gestion, la seule valeur indiquant la version publiée est revision.
  • sys.createdBy et sys.updatedBy : inclus uniquement lorsque le publishWithAuthor du Content Type est activé, ils pointent vers l'auteur et le modificateur. Dans l'exemple ci-dessus, cette option est désactivée, donc ces deux clés sont omises.
  • fields : contient la valeur de chaque champ sous la forme { apiName: value }. Contrairement à la carte de locales de CMA et ACMA ({ apiName: { locale: value } }), ACDA ne contient qu'une seule valeur, celle de la locale consultée. Dans l'exemple ci-dessus, la photo principale photo est omise car elle n'a pas de valeur pour cette locale.

Le Media est renvoyé de la même façon, sous forme livrée et publiée : sys ne contient que revision, sans version, status ni publish. Le Media omet toujours les informations d'auteur (createdBy et updatedBy). Le fields.file du Media est lui aussi renvoyé comme un objet unique correspondant à la locale consultée.

API

Les trois points d'accès sont tous des consultations (GET), et le paramètre de requête locale détermine la langue reçue (un code pour cette locale, l'omission pour la Locale par défaut, * pour la carte complète, voir ci-dessus).

  • ACMA : API de gestion par laquelle les membres créent et modifient leur propre contenu.
  • API Auth : émission du jeton d'appel ACDA.
  • Connexion ServiceUser (concept) : configuration de ServiceLogin, ServiceUserRole et des affectations.