日前，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而在于没有用好它？或者它一直是很好的模式，而现在又得到第二次机会？