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

译者 马国耀 在SOA领域摸爬滚打4年多,做过许多国内外SOA项目,熟知SOA原则/方法以及ESB/BPM等。目前对云计算及其SOA的融合持有浓厚兴趣。

This entry was posted in Achitecture, SOA. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s