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

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

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

大部分API提供者设计的目的，都是为了维护数据模型的纯净度。然而在构建 [编排层]时，我们需要做好在某些时候牺牲纯净度以换取优化和/或性能的心理准备。

许多API团队设计API，以求让自己更易于提供支持。然而在构建 [编排层]时，我们需要做好可能会对增加团队工作复杂性的心理准备。

了解API受众的广度非常重要。针对受众的不同成分，有时候我们或许只需要 [编排层]。而在其他一些情况中，我们除了[编排层]之外，或许还需要[万应灵药]式的基础。

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

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

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

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