ACMA (App Content Management API)

最后更新：2026年6月22日

ACMA(App Content Management API)是供已注册产品的会员，也就是 ServiceUser，直接操作 Content 和 Media 的 API。可以理解为 Weegloo User 通过 CMA 操作内容的同样工作，由会员身份来执行。会员通过 ACMA 创建（Create）、读取（Read）、修改（Update）和删除（Delete） Content 和 Media。每项操作的允许范围由 ServiceUserRole 决定。

调用 ACMA 时使用 ServiceLogin 签发的 Bearer 令牌。该令牌仅在 ACMA 和 ACDA 中有效，不能用于 CMA 和 CDA（令牌签发流程参见 Auth API）。会员所遵循的框架，即 Content Type，不在 ACMA 中创建或修改。Content Type 由 Weegloo User 在 CMA 中管理，ACMA 没有 Content Type 的创建和修改端点。

与 CMA 的不同之处

ACMA 对应于 CMA，但在身份、所有权范围和发布行为上有所不同。

项目ACMA (ServiceUser)CMA (Weegloo User)
身份在 ServiceLogin 注册的 ServiceUser。权限由 ServiceUserRole 决定。Weegloo User。权限由 SpaceRole 决定。
访问范围读取、修改、删除的范围由 ServiceUserRole 决定（与 ACDA 的按会员读取方式相同）。在角色规则中将 createdBy 设为 :self，则该操作仅限于自己创建的资料，通常修改和删除会这样应用。读取则可在角色允许的范围内包含其他会员的资料。在 SpaceRole 允许的范围内操作整个 Space 的资料。
创建时发布创建 Content 和 Media 后立即发布。没有单独的发布调用。Content 创建后需要单独的发布调用才能进入交付路径。
删除时发布删除时自动一并取消发布。无需先取消发布。处于发布状态的资料通常先取消发布后再删除。
本人资料通过 GET /me 查询（不是 /spaces/{spaceId}/me）。GET /me（当前 Weegloo User）。
Content Type没有创建和修改端点。框架由 CMA 负责。创建、修改和发布 Content Type。

ServiceUser.isAdmin 为 true 的会员，仅能额外执行删除其他会员资料这一项。这是在角色允许的操作之上叠加的权限，并不会增加对其他会员资料的修改权限或读取权限。即便如此，也只能在该会员的 ServiceUserRole 所允许的操作范围内进行。

上述行为（所有权范围、创建时自动发布、删除时自动取消发布、isAdmin 范围）的详细说明，请参见 ServiceUser 登录（概念）。

我的信息 (Me)

GET /me 返回当前令牌的 ServiceUser 本人信息。与 CMA 不同，无需经过 Space 路径，直接调用 /me。

以下是 ServiceUser 的响应结构。sys 中包含身份和注册信息，正文中包含 nickname、avatarUrl 等用于显示的属性。

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ",
    "type": "ServiceUser",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "provider": "google",
    "email": "minji.kim@example.com",
    "createdAt": "2026-06-17T09:12:03.114Z",
    "updatedAt": "2026-06-17T09:12:03.114Z"
  },
  "nickname": "Minji",
  "avatarUrl": "https://lh3.googleusercontent.com/a/example-avatar",
  "enableLogin": true,
  "isAdmin": false
}

主要键：

  • sys.id：ServiceUser 的唯一标识符。会员创建的 Content 和 Media 的 createdBy 指向该值。
  • sys.type：资源种类，ServiceUser 始终为 "ServiceUser"。
  • sys.space：指向该会员所属 Space 的引用。
  • sys.provider：登录所使用的提供方（例如 google）。
  • sys.email：登录提供方所提供的电子邮件地址。
  • nickname：会员的显示名称（必填）。
  • avatarUrl：头像图片地址（可选）。
  • roleOverride：仅对该会员应用其他 ServiceUserRole 时，指向该角色的引用（可选）。不设置时遵循 ServiceLogin 的默认角色。
  • enableLogin：是否允许登录。
  • isAdmin：为 true 时可删除其他会员的资料（参见上文 与 CMA 的不同之处）。

只能修改 nickname 和 avatarUrl。provider、email、isAdmin 等值不由会员本人更改。

Content

Content 是遵循 Content Type 这一框架的单个资料。如果是服装店商城，那么遵循“商品” Content Type 的每一个商品就是 Content。在 ACMA 中，会员通过绑定到 Space 和 Content Type 的路径（/spaces/{spaceId}/content-types/{contentTypeId}/contents）操作自己的 Content。

以下是演示 Space 中的一个“商品” Content。

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7OGhwhlqvAvq",
    "type": "Content",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
    "publish": {
      "version": 3,
      "at": "2026-06-16T14:35:11.210Z",
      "firstAt": "2026-06-15T15:16:20.180Z",
      "counter": 3,
      "by": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } }
    },
    "createdBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } },
    "createdAt": "2026-06-15T15:16:12.151Z",
    "updatedAt": "2026-06-16T14:35:11.210Z",
    "updatedBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } },
    "version": 4,
    "status": "Published"
  },
  "fields": {
    "price": { "ko-KR": 18000 },
    "description": { "ko-KR": "이중 진공 단열로 보온·보냉이 오래갑니다. 500ml 대용량." },
    "photo": {},
    "productName": { "ko-KR": "스테인리스 텀블러 500ml" }
  },
  "metadata": { "tags": [] }
}

主要键：

  • sys.id：Content 的唯一标识符。会填入单个查询、修改、删除路径的 {contentId}。
  • sys.contentType：指向该 Content 所遵循 Content Type 的引用。
  • sys.status：发布状态。在 ACMA 中创建的 Content 会立即发布，返回 Published。
  • sys.version：资源版本，每次变更加 1。
  • sys.publish：发布历史（version、at、firstAt、counter、by）。
  • fields：以 { apiName: { locale: value } } 形式存放各字段的值。上例以 ko-KR 区域设置存放了 price、description、photo、productName。没有值的字段（photo）为空对象。
  • metadata.tags：附加在该 Content 上的 Tag 列表。

列表查询接受标准查询参数（limit、skip、next、prev、order、select、include），响应会一并返回 items 数组和 links（分页游标）。

Media

Media 是上传的文件资产（图片、视频、文档等）。会员要创建 Media，需先通过 Upload API 上传文件以获得 Upload，并将该 Upload 的 sys.id 放入 Media 创建请求中。在 ACMA 中，Media 同样在创建的同时自动发布。

以下是上传到演示 Space 的水杯照片 Media。

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7OGjUMsPV3uU",
    "type": "Media",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "publish": {
      "version": 1,
      "at": "2026-06-15T15:17:30.825Z",
      "firstAt": "2026-06-15T15:17:30.825Z",
      "counter": 1,
      "by": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } }
    },
    "createdBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } },
    "createdAt": "2026-06-15T15:17:30.589Z",
    "updatedAt": "2026-06-15T15:17:30.825Z",
    "updatedBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } },
    "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/3uU/3trmXRM3RqbgSnifyg7OGjUMsPV3uU/ko-KR/1/tumbler.png",
        "detail": { "size": 50847, "image": { "width": 900, "height": 900 } }
      }
    }
  },
  "metadata": { "tags": [] }
}

主要键：

  • sys.id：Media 的唯一标识符。会填入单个查询、删除路径的 {mediaId}，也是 Content 引用照片时所指向的值。
  • sys.status：发布状态。在 ACMA 中创建的 Media 会立即发布，返回 Published。
  • fields.title、fields.description：以区域设置映射存放资产的标题和说明（可选）。
  • fields.file：按区域设置的文件信息（必填）。处理完成后会填入 url（用于交付的地址）、mimeGroups、detail（大小、图片分辨率等）。

Media 创建请求的 fields.file 中放入处理前状态的 Upload 引用。每个文件项都包含 fileName、contentType、mimeGroups、state、upload，其中 state 始终为 "PENDING"，upload 中放入通过 Upload API 获得的 Upload 的 sys.id。创建后平台随即处理文件，处理完成后便会像上面的响应那样填入 url 和 detail。