REST API 用得也痛苦

日前，Subbu Allamaraju 在博文中谈到当前REST API 使用过程中的一些问题，并提出了一些改进办法。

Allamaraju 认为，人们在使用 REST API 时面临的几个主要问题是：

接口不匹配：因为 API 是由其提供者创建的，所以往往体现创建者的视角——几乎所有 API 的最大共同特征都是最大化其使用和重用。这一特点往往导致 API 的粒度过细，这样每个消费者就可以调用 API 集合的任何子集，并且可按照任何次序进行调用。

在此过程中， [提供者] 必定要牺牲消费者的某些特殊需求，而且尽量坚持于那些通性征。这就导致了消费者需求和 API 供应之间的不匹配。

编写客户端代码比较慢，繁琐而且经常重复：使用细粒度 API 产生多次调用，然后将所有返回结果聚合起来。

如果没有一个处理这些 API 的 SDK，你需要花很长时间去处理 2*n 次调用以及其响应（译注：Allamaraju 在博文中举了一个示例，该示例的客户需求是查询一组产品的 ID、详细信息以及相应的用户评价，在该场景中首先需要先做一次查询，得到 n 个产品 ID，然后对每个 ID 做两次调用，分别是查询详细信息和查询用户评价，如总共的调用次数为 2*n）。

除此之外，每次 API 调用时客户端程序还需要构建请求和解析响应。

等待 API 提供者的功能增强往往耽误时间：因为 API 提供者要支撑许多消费者，并且按照自己的工作计划行事，该计划往往与消费者的计划不同，特殊的消费者需求很难与提供者的计划同步。此外，因为提供者通常要衡量 API 的重用，所以很难为某个特定的消费者单独提供一个 API……

API 调用常常很繁琐：繁琐的客户端指的是为了完成一次功能需要发出多次 HTTP 请求，从而导致严重的性能下降及网络超载。不论从性能还是从网络利用率的角度看，直观的感觉是使用粗粒度的 API 会更好。

RESTful API 的一致性没有我们相像的那么重要：理想情况下，保持 API 实现之间的一致性固然很好，但是 Allamaraju 认为，REST API 的最重要的特性是互操作性：

我宁可把时间花在互操作性上，而不是一致性上。

Allamaraju 在博文结尾如此总结：

客户端的主要挑战是对发起请求（fork）和合并响应（join）的聚合、并行处理和编排。

那么，如何解决这一问题呢？Allamaraju 提到：

……在 eBay，我的团队正在建设一个新平台，通过它可简化上述案例： - 减小调用 API 的客户端代码规模

• 根据需要自动编排 API 调用
• 通过包装现有的以提供者为中心的 API，创建新的面向消费者的 API
• 降低带宽使用率及延迟

Allamaraju 不是唯一提到此类平台的人，早在今年旧金山举行的 QCon 上，来自 NetFlix 的 Daniel Jacobson 就介绍过一个正在实现中的相似解决方案。

Allamaraju 和 Jacobson 提出的解决方案极有意义，但又不禁让人想问：它和 ESB 有何区别？而 ESB 却好像被指为致使 SOA 失败的主要原因之一？难道问题不在于 ESB 而在于没有用好它？或者它一直是很好的模式，而现在又得到第二次机会？

查看英文原文： APIs Can Be a Pain