学习目标
完成本单元后，你将能够：
- 解释使用 API 规划框架的好处。
- 识别构成 API 规划框架的五个要素。
API 的世界
十多年来，API 改变了各行业工程师设计和开发软件的方式。开发团队利用现成的开放 API，更快地创建和交付解决方案，Salesforce API 也不例外。例如在 Platform API Basics 模块中，你会学到用 REST API、SOAP API、Bulk API 和 Pub/Sub API 来操作数据。仅 REST API 就有 40 多个顶层资源，每个都代表一组 Salesforce 能力。
在选择 Salesforce API 或开始开发之前，你需要一个好的软件设计计划。本模块教你如何使用 API 规划框架，从一开始就设计可扩展的解决方案、选对 API。
给规划赋予结构
构建高性能、可扩展、安全的解决方案需要仔细规划。在 ALM 流程的规划阶段，你为项目制定开发计划。Salesforce API 可以针对不同用例和复杂度的工作流进行优化，因此需要先给规划建立结构。以 Salesforce CRM API 为例，它们的协议、数据格式和通信方式各不相同：
- REST API（REST / JSON、XML / 同步）、SOAP API（SOAP / XML / 同步）、Chatter REST API、User Interface API、Analytics REST API。
- Bulk API（CSV/JSON/XML / 异步）与 Bulk API 2.0（CSV / 异步，推荐替代 Bulk API）。
- Metadata API（SOAP / XML / 异步）、Pub/Sub API（gRPC / 二进制 / 异步流，含 Platform Events 和 Change Data Capture Events）。
- Apex REST API、Apex SOAP API、Tooling API。
选对 API 的好处
面对众多 API，为项目选一个合适的 API 虽具挑战却必不可少。使用不适合软件设计的 API，可能导致写出多余代码，甚至消耗不必要的资源；这样你就无法充分发挥工具的作用，最终让终端用户体验变差。因此要确保所选 API 足够灵活，能随着设计的变化和扩展而适应。随着项目成长，需要考虑的变量很多。
为规划阶段赋予结构
在 ALM 规划阶段，你收集需求、界定项目范围，绘制架构设计、制定集成策略，并识别所需的技术工具（如 API）。这些活动要兼顾开发和部署阶段。为了更好增强规划、帮你在 API 图景中导航，你需要一个 API 规划框架。
API 规划框架：五个要素
API 规划框架由五个要素构成，帮助你在正确的时间确定正确的 API 工具，从而设计出更可扩展的解决方案：
- 用户体验：终端用户体验是什么？开发者需要什么工具？
- 对象与记录：你在处理什么数据？
- 操作：你想对数据做什么？
- 增长与规模：集成如何随数据集增长而扩展？
- API 限制与配额：你的资源在使用多少 API 资源？
后续单元将逐一深入讨论，首先从用户体验开始。
定义用户体验
本单元讨论为何要带着用户体验来规划技术设计，以及什么是开发者体验。
学习目标
完成本单元后，你将能够：
- 解释为什么规划时要考虑用户体验。
- 解释什么是开发者体验。
带着用户体验来规划
在技术设计中平衡适量的用户体验（UX）是件难事：既想让工具未来可扩展、在整个生命周期中更易维护，又想用最合适的设计。最好的计划，是为项目找到用户体验与技术设计的恰当平衡点。
理解用户体验
早在进入设计/构建阶段之前，就应该开始思考终端用户。事实上，用户体验应当成为规划阶段的中心，这样能及早发现潜在的挑战和挫折——你不希望建好工具后，用户却说「我搞不懂这东西怎么用」。
规划项目时，问自己这些问题：
- 你想解决什么问题？
- 谁是终端用户或受众？
- 他们将如何与你的解决方案交互？
虽然及早关注并共情终端用户很重要，但也不要忽视开发者体验——终端用户的需求与你不同，而你的体验同样重要。
别忘了开发者体验
你可能会问：「开发者体验是什么？开发者不是解决方案的终端用户，他们是构建解决方案的人。」开发者确实在构建解决方案；但开发者体验涵盖的是构建该解决方案所需的技术复杂度——这要求技术设计纳入开发者将经历的开发、维护和发布活动。
终端用户体验是软件生命力的关键，但如果不纳入开发者体验，项目设计就难以扩展。同时考虑两类用户体验，需要平衡与仔细规划。
思维练习
通过一个思维练习来实践「带着 UX 来规划」。阅读以下问题，把每个问题应用到 ALM 流程的各个阶段，目标是帮你发现尚未考虑的其他因素，从而确定哪个 API 资源最适合你的项目。
定义终端用户体验：终端用户是谁？他们使用你解决方案的主要用例是什么？要满足哪些服务级别协议（SLA）才能带来好体验？终端用户需要通过哪些渠道访问解决方案？
定义开发者体验：是否存在对其他工具的技术依赖？你想用解决方案达成什么结果？项目范围内还有哪些 Salesforce 解决方案和系统？数据是什么格式？你面对的是客户端还是服务端的体验？
确定数据模型与操作
本单元开始映射数据模型结构，并学习关系如何在数据库操作中扮演关键角色。
学习目标
完成本单元后，你将能够：
- 解释对象关系在数据建模中的重要性。
- 解释什么是操作，以及它们对你的 API 有多重要。
概述
学完如何把不同类型的用户体验纳入项目设计后，接下来开始映射数据模型结构，并了解关系在数据库操作中扮演的关键角色。
识别对象与字段
在探索数据模型结构之前，必须先识别项目所需的对象和数据类型。在 Salesforce 中构建对象、创建字段，就是定义元数据（关于数据的数据），它告诉系统数据如何存储、处理以及与其他元数据关联。
开始数据建模时，写下项目所需的对象、字段和数据类型。若设计中引用的某些对象已存在于 org 中，可在 Setup 的 Object Manager 查看对象及字段的完整概览，或用某个 API 发起端点调用。思考这些问题：解决方案是否包含非 Salesforce 系统的对象和字段？数据需要哪些对象和字段类型？每个对象的关键标识符是什么？
关系为何重要
对象和字段的元数据在决定数据如何流经项目方面至关重要。在 Salesforce 中创建某些字段时，会自动构建对象之间的关系——这些字段类型包括主从关系（master-detail）、间接查找（indirect lookup）、外部查找（external lookup）和查找（lookup），它们创建了一对一（1:1）、一对多（1:N）和多对多（N:N）关系。
对象之间的关系决定了数据结构和数据处理方式。思考：各对象的记录将如何创建？系统中已有对象之间的关系是什么？对象之间是否存在依赖？
定义数据模型
数据建模决定了表和系统之间的整体结构与关系。数据建模图能帮你理解解决方案的可能性，展示数据在数据库各层的情况，并帮你轻松识别数据负载。了解这些因素，有助于在扩展设计时确定哪个 API 资源更适合项目。
定义数据模型结构时思考：项目扩展时数据如何维护？需要什么类型的报告和分析？数据将如何在系统中收集和处理？
开始数据建模
花点时间绘制数据模型——此时用专业的映射工具还是纸笔并不重要，目标是映射架构、定义数据如何在解决方案中流动。绘制数据模型、识别要执行的操作时，不妨问一句：「有对应的 API 吗？」
你可以在 Salesforce 中用 Schema Builder 实时查看对象及其关系：在 Setup 的 Quick Find 中输入 Schema Builder 即可。它会生成可视化，展示对象之间以及对象内字段之间的关系。
识别操作
Salesforce API 是设计精良、可复用的资源，开箱即用地内置了功能——它们让你能对项目设计中的对象执行不同操作。可以把操作看作能修改对象中数据的事务，例如记录可以被创建、插入、更新甚至删除。SOAP API 和 REST API 都支持这些常见操作，但实现方式不同：SOAP API 支持 XML 格式数据，而 REST API 同时支持 XML 和 JSON。
为操作选对 API
选择 API 执行操作前，先确定你想对数据做什么，以及 API 在你的系统中如何运作。思考：数据结构的「真相源」（source of truth）是什么？处理的数据量多大？终端用户消费解决方案时数据流向何方？什么数据在何时写入数据库？
接着确定需要 API 提供的操作类型：操作会作用在多少条记录上？操作应同步还是异步运行？操作应单独、按批还是按批量工作负载执行？事务失败时会发生什么？这些操作的执行和性能如何影响终端用户体验？
此时你只是在收集「哪个 API 资源能执行你要的操作」的信息。识别操作和所设计的用户体验，能帮你缩小 API 选项范围。
为增长与规模而设计
本单元聚焦框架的最后两个要素：增长与规模，以及 API 限制与配额。
学习目标
完成本单元后，你将能够：
- 从开发者的视角描述「增长」的含义。
- 解释为什么为规模而设计解决方案很重要。
规划增长与规模
你为项目选择的 API，在很大程度上决定了项目的可扩展性。规划阶段的开发团队往往只关注工具发布时该如何运作，而忽略了为增长和规模做规划。对大多数企业来说，增长意味着月活用户数、回头客频率或某个工具的安装量。然而，从开发者的视角看，增长的含义有所不同。
从开发者的视角，增长关乎系统在资源被消耗时的表现。规划规模时，还应考虑系统在数据量增长时的运行情况。
测试解决方案的规模
随着设计的持续扩展，最好建立一套高质量的测试流程。你要定期对系统做压力测试，挑战设计，看它在数据增长时能多大程度地支撑增长。
思考以下问题，帮助规划增长与规模：
- 你所用资源的处理阈值是多少？
- 应该用什么成功指标来定义增长？
- 系统在 ALM 全流程中是如何被测试的？
你可能需要更多或不同的资源来打造可扩展的设计。要思考这些新增资源会如何影响开发者体验，以及达到资源阈值时的开销成本。你不想在后期产生切换成本，或花更多时间去开发修补方案。实施之初所做的 API 选择，应同时评估「今天的场景」和「未来」。
API 限制与配额
最后，要确保自己在可用资源范围内工作。Salesforce 架构是多租户的，这意味着各 org 共享一组资源。每个 Salesforce org 都被分配了一定数量的每日 API 请求。每个 org 的资源总量要包含进入该 org 的所有调用。目标就是设计一个在这些配额内运行的解决方案。一个高效、可扩展的解决方案，意味着你能为其他项目留出更多的 API 限制。
检查你的限制与配额
在 Platform API Basics 模块中，你会学到多种查看 Salesforce 核心 API 剩余配额的方法。例如，导航到 System Overview 页面上的 API Usage 框，查看系统概览：在 Setup 的 Quick Find 中输入 System Overview，然后选择 System Overview。或者使用 Lightning Platform REST API 中的 /limits 资源。
另一种查看 org 当前可用资源的好方法，是通过命令行界面使用 Salesforce CLI：
- 完成 Quick Start: Salesforce DX 项目，启用 DevHub 并授权 Salesforce CLI 访问你的 org。
- 在终端运行以下命令查看 org 当前可用资源：
sf limits api display --target-org [alias or username]
思维练习
在为 Salesforce org 设计解决方案时，要考虑新实现会如何影响现有集成。确保当前工作负载和其他 org 配置不会被打断。通过思考以下问题，判断 API 是否能在你的设计中正常运作：
- 还有多少其他集成在向你的 org 发起 API 请求？
- 你的 org 多久会达到每日 API 请求配额上限？
- 你 org 的每日 API 请求预算是多少？
- 要满足你的用例和数据量，需要多少次 API 请求？
总结
API 是把我们构建的应用连接到外部世界的核心。现在你有了一个扎实的规划框架来指导自己，就能用更少的代码做更多的事。可以查看 Salesforce 帮助文章「Which API Do I Use?」，了解 API 配额和策略的细分，帮你做出正确的 API 调用。