AEM Headless as a Cloud Service 快速入门 getting-started

在 AEM Headless 开发人员历程的这部分中，了解使用 AEM Headless 启动您自己的项目所需满足的条件。

迄今为止的故事 story-so-far

在 AEM Headless 历程的上一个文档了解 CMS Headless 开发中，您学习了 Headless CMS 的含义的基本理论，现在应：

本文基于这些基础知识编写，以便您了解如何使用 AEM 实施 Headless 解决方案。

目标 objective

本文档可帮助您在自己的项目上下文中了解 AEM Headless。阅读本文档后，您应：

AEM 基础知识 aem-basics

在 AEM 中定义 Headless 项目之前，请务必了解一些基本的 AEM 概念。

创作实例 author

最简单地说，AEM 由一个创作实例和一个发布实例构成，二者协同工作以创建、管理和发布您的内容。

内容在创作实例上开始。内容作者在该实例上创建内容。创作环境为作者提供了各种工具来创建、组织和重用他们的内容。

发布实例 publish

在创作实例中创建内容后，必须发布内容以供其他服务使用。发布实例包含所有已发布的内容。

预览服务 preview

在发布到“发布”实例之前，您还可以将内容片段发布到​ 预览服务，以进行测试和审查。这是通过​ 内容片段 ​控制台完成的。

复制 replication

复制是一项将内容从创作实例传输到发布实例的操作。当作者或其他具有适当权限的用户发布内容时，AEM 会自动完成此操作。

AEM 基础知识摘要 aem-basics-summary

在最简单的层面上，在 AEM 中创建数字体验需要执行以下步骤：

AEM Headless 通过提供功能强大的工具来管理 Headless 内容来奠定这一技术基础，这将在下一部分中介绍。

AEM Headless 基础知识 aem-headless-basics

AEM 的 Headless 功能基于几项关键功能。历程的后面部分将详细解释这些功能。现在，只需要了解有关这些功能的用途和名称的基础知识。

内容片段模型 content-fragment-models

内容片段模型定义您在 AEM 中创建和管理的数据及内容的结构。它们在某种程度上用作内容的基架。选择创建内容时，作者将从您定义的内容片段模型中选择，这会引导他们创建内容。

内容片段 content-fragments

您可使用内容片段设计、创建、管理和发布独立于页面的内容。利用它们，您可以准备内容以用于多个位置和多个渠道。

内容片段包含结构化内容，可以采用 JSON 格式投放。

GraphQL API 和 REST API apis

为了以 Headless 方式修改您的内容，AEM 提供了两个功能强大的 API。

您将在 AEM Headless 历程的后面部分中了解这些 API 及其使用方式。或参阅下面的其他资源部分以获取更多文档。

Headless 集成级别 integration-levels

AEM 支持 CMS 的完全 Headless 模型和传统的全栈或 Headful 模型。然而，AEM 不仅提供了这两种独特的选择，还支持结合了两者优势的混合模型，从而让您的 Headless 项目具有独特的灵活性。

为了确保您理解 Headless 概念，此 AEM Headless 开发人员历程重点说明了纯 Headless 模型，使您无需在 AEM 中编码即可尽快启动并运行。

但是，在您了解 AEM 的 Headless 功能后，就应意识到额外的混合可能性。下面列出了这些情况以供您了解。在历程结束时，您会更详细地了解这些概念，以防您的项目需要这种灵活性。

您有无头内容的外部使用者，例如单页面应用程序 (SPA)。 already-have-a-spa

假设您的基本要求是至少将内容从 AEM 交付到现有外部服务。

级别 1：内容片段集成 - 传统 Headless 模型 level-1

此集成级别是传统 Headless 模型，允许您的内容作者在 AEM 中创建内容，并使用 GraphQL 以 Headless 方式将内容交付给任意数量的外部服务，或者使用 Assets API 从外部服务编辑内容。无需在 AEM 中进行编码。

在此模型中，AEM 仅用于使用 AEM 内容片段创建和提供内容。内容的呈现和交互工作将委派给使用的外部应用程序，通常是单页应用程序 (SPA)。

级别 2：将 SPA 嵌入 AEM 中 - 混合模型 level-2

此级别的集成基于级别 1 构建，但也允许将外部应用程序 (SPA) 嵌入到 AEM 中，以便内容作者能够在 AEM 中外部应用程序的上下文中查看内容。该应用程序还可以支持在 AEM 中对外部应用程序进行有限的编辑。

此级别的优势是，允许内容作者以 Headful 方式在 AEM 中灵活地创作内容，其内容将通过嵌入式外部 SPA 在上下文中呈现，同时仍以 Headless 方式交付内容。

级别 3：在 AEM 中嵌入并完全启用 SPA – 混合模型 level-3

此级别的集成基于级别 2 构建，使外部 SPA 中的大部分内容都可在 AEM 中进行编辑。

您没有 Headless 内容的外部使用者，例如单页应用程序 (SPA)。 do-not-have-a-spa

如果您的目标是创建以 Headless 方式从 AEM 消耗内容的 SPA，则可使用内容片段等功能管理您的 Headless 内容，还可用 AEM 的 SPA 编辑器框架构建 SPA。

借助 SPA 编辑器，SPA 不仅可以使用 AEM 中的内容，还可以由内容作者在 AEM 中进行完全编辑，这将使您能够在 AEM 中灵活地进行 Headless 交付和上下文编辑。

要求和先决条件 requirements-prerequisites

在开始 Headless AEM 项目之前，需要满足多个要求。

知识 knowledge

工具 tools

定义项目 defining-your-project

对于任何成功的项目，请务必明确定义项目的要求以及角色和职责。

范围 scope

请务必明确定义项目的范围。范围告知验收标准，并让您创建完成的定义。

您必须提出的第一个问题是“我尝试使用 AEM Headless 实现什么目标？”一般来说，答案应该是您拥有或将来会拥有您使用自己的开发工具而非 AEM 构建的体验应用程序。此体验应用程序可以是移动应用程序、网站或任何其他面向最终用户客户的体验应用程序。使用 AEM Headless 的目标是为您的体验应用程序提供在 AEM 中创建、存储和管理的内容，并使用最先进的 API 调用 AEM Headless 以直接从体验应用程序中获取内容甚至完整的 CRUD 内容。如果这不是您想执行的操作，您可能需要返回 AEM 文档，并找到更适合您要完成的操作的部分。

角色和职责 roles-responsibilities

任意单个项目的角色各不相同，而在 AEM Headless 开发的内容中需要考虑的重要角色是：

管理员 administrator

管理员负责系统的基本设置和配置。例如，管理员在 Adobe User Management 系统（称为 Identity Management System (IMS)）中设置您的组织。Adobe 在 IMS 中创建您的组织后，管理员是组织中第一个收到来自 Adobe 的电子邮件邀请的用户。管理员可以登录 IMS 并添加其他角色的用户。

在管理员配置用户后，他们将获得对所有 AEM 资源的访问权限，以完成他们作为投稿人的工作，并使用 AEM Headless 交付体验应用程序。

管理员应是负责以下工作的用户：设置 AEM 并准备运行时环境以使内容作者能够创建和更新内容，并使开发人员能够使用 API 来获取或修改其体验应用程序的内容。

内容作者 content-author

内容作者创建和管理 AEM 以 Headless 方式交付的内容。内容作者使用内容片段编辑器和各种控制台等 AEM 功能管理其内容。

内容作者应牢记以下最佳实践。

规划翻译 translation

在项目的一开始就规划翻译。将“翻译专家”视为一个单独的角色，其职责是定义应翻译的内容、不应翻译的内容以及哪些已翻译内容可由区域或本地内容制作者修改。

根据需要的内容翻译制定计划。

清楚了解您的内容更新工作流。系统必须支持的审批流程是什么？是否能利用 AEM 工作流来自动实施此过程？

可以利用您的内容层级来简化翻译。

请参阅其他资源部分，了解有关 AEM 工作流和翻译工具的其他文档，包括指向 AEM Headless 翻译历程的链接。

利用内容层级 content-hierarchy

文件夹层级可以解决与内容管理有关的两个主要问题：

AEM 允许灵活的内容结构，并且层级可以任意大。不过，请务必了解一点，文件夹结构中的任何更改都可能对现有查询产生意外后果，这些查询依赖内容路径。因此，预先清楚列明的明确定义的层级可能对您的内容作者会很有用。

也可以将文件夹限制为仅允许某些类型的内容（基于内容片段模型）。建议始终明确指定层级中的所有文件夹允许哪些模型。为给定文件夹指定允许的内容：

通过创建适当的内容结构，可以更轻松地跨渠道协调 Headless 内容创作，以最大程度地重用内容。跨多个渠道利用内容可大大提高内容生产效率并增强更改管理。

建立正确的命名惯例 naming-conventions

对于内容作者而言，内容片段名称必须是描述性的。AEM 在存储库级别透明地处理转义和/或截断使用了 ID 的名称。因此，内容作者提供的逻辑名称应始终可读并代表内容。

有关 AEM 页面命名惯例的其他文档，请参阅其他资源部分。

不要过度扩展内容嵌套 content-nesting

内容片段在 AEM 中用于创建 Headless 内容。AEM 支持内容片段的最多 10 个层次的内容嵌套。不过，请务必记住，AEM 必须以迭代方式解析父内容片段中定义的每个引用，然后检查所有同级元素中是否有任何子引用。这些操作会快速累加并变成性能问题。

作为一般经验法则，内容片段引用的嵌套不应超过五层。

内容架构师 content-architect

内容架构师分析必须以 Headless 方式交付的数据的要求并定义此数据的结构。这些结构在 AEM 中称作内容片段模型。内容片段模型用作内容作者创建的内容片段的基础。

定义内容片段模型时的有用方法是，创建映射到使用内容的应用程序的 UX 组件的模型。

由于内容作者在创建新内容时会持续与模型进行交互，因此，将模型与 UX 保持一致有助于它们可视化生成的数字体验。要提高一致性，您可以向表示 UX 元素的内容片段模型分配图标，以便作者能够根据视觉提示直观地选择正确的模型。

开发人员 developer

开发人员负责将在 AEM 中以 Headless 方式创建的内容交付给该内容的使用者，后者通常可以是单页应用程序 (SPA)、渐进式 Web 应用程序 (PWA)、网上商店或 AEM 外部的其他服务。

GraphQL 充当 AEM 和 Headless 内容使用者之间的“粘合剂”。GraphQL 是用于在 AEM 中查询必要内容的语言。

开发人员在计划查询时应记住几条基本建议：

对于使用 AEM 的典型 Headless 实施，开发人员无需了解 AEM 的编码知识。

性能要求 performance-requirements

要使任何项目获得成功，在创建任何内容之前都必须考虑性能。

您必须了解用户/访客的期望并为此进行设计。设置服务水平目标 (SLO) 并进行衡量，了解您是否达到了用户期望。

流量模式 traffic-patterns

要了解流量和流量模式，首先要收集您过去了解的信息，然后预测未来几年的预期增长。需要考虑的一些最重要的变量是：

更新频率 update-frequency

通常，不同的体验部分会具有不同的内容更新频率。了解这一点对于能够微调 CDN 和缓存配置非常重要。这也是内容架构师的重要输入，因为他们将设计模型来表示您的内容。请考虑：

后续内容 what-is-next

现在您已完成 AEM Headless 开发人员历程的这一部分，您应：

您应该继续您的 AEM Headless 历程，接下来查看文档首次 AEM Headless 使用体验的路径，其中您将了解如何设置必要的工具以及如何开始思考在 AEM 中为您的数据建模。

其他资源 additional-resources

我们建议您查看文档首次 AEM Headless 使用体验的路径来继续 Headless 开发历程的下一部分，以下是一些其他可选资源，这些资源对本文档中提到的一些概念进行了更深入的探究，但并非继续 Headless 历程所必需的。