业务流程层的 API

  • Saul Caganoff
  • 李彬

2013 年 12 月 27 日

话题:REST架构

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

REST架构