业务流程层的 API

Netflix API 的工程主管 Daniel Jacobson 最近在 The Next Web 上发表了一篇文章，他表示：我们需要理解谁是 API 的使用对象，以及他们的使用的方式，并在此基础上进行 API 设计。这看起来是显而易见、理所应当的事情，然而 Daniel 接下来写道：过去那种传统的“万应灵药”般的面向资源的 API，或许并不能满足使用我们 API 的用户中最重要的那些人。良好的 API 设计不只是关于“资源建模、负载格式、如何管理系统版本以及安全”，更加根本的问题是：“谁是这些 API 的主要受众，以及我们应该如何来针对他们进行优化？”

面向资源的 API 或许适用于“广泛的未知开发者”，但实际上大部分组织机构需要满足的是“少量已知开发者”的需求，以及特定的用例。“他们或许就是 API 团队楼下的工程师、或许是一家被雇用以开发 iPhone 应用的合约公司，又或是来自合作公司的一支工程团队，”Daniel 写道，而优化 API 的机会正蕴藏在这些情景中。

许多公司正在逐渐向其体系架构中引入 API 编排层——Daniel 将其定义为“一个抽象层，它运用通用建模的数据元素和 / 或特性，并以一种更具体的方式处理它们，从而为某个目标开发者或应用做准备。”Daniel 列出了部分编排层的关键准则如下：

1. 大部分 API 提供者设计的目的，都是为了维护数据模型的纯净度。然而在构建 [编排层] 时，我们需要做好在某些时候牺牲纯净度以换取优化和 / 或性能的心理准备。
2. 许多 API 团队设计 API，以求让自己更易于提供支持。然而在构建 [编排层] 时，我们需要做好可能会对增加团队工作复杂性的心理准备。
3. 了解 API 受众的广度非常重要。针对受众的不同成分，有时候我们或许只需要 [编排层]。而在其他一些情况中，我们除了 [编排层] 之外，或许还需要 [万应灵药] 式的基础。

第二条准则让人想起了接口设计中常见的类似情况：为一个“聪明的”视频记录软件增加内部复杂度，以便让外部用户更易于使用。

在文章的最后，Daniel 给出了三个常见的用例，包括将编排层用于针对特定设备的包装器、支持一套基于查询的 API，以及提供基于经验的 API。Daniel 表示，针对特定设备的包装器是他所见过的最常见的用例，例如针对 iPhone 优化的 API 包装器。此类针对特定设备的包装器一般由 API 团队为特定消费者提供。相反，基于查询的 API 把权力交给了 API 使用者——让使用者掌控，“允许他们就像访问数据库一样，通过灵活的参数和负载去查询 [资源]”。

Netflix 采用的模型是基于经验的 API，同时也混合了其他两个用例——针对特定设备设计和实现，并由 API 用户所拥有的包装器。负责的部门被划分为 API 团队——负责以通用的、可复用的方式提供数据；以及使用者——掌握数据格式和交付。

Daniel 总结道，API 团队需要将 API 的使用者视作设计过程中的伙伴进行协作，以便尽可能地让最终用户获得最佳体验。

查看英文原文： The API Orchestration Layer