云 API 纷争又起:RPC 还是 REST

  • Mark Little
  • 马国耀

2011 年 2 月 20 日

话题:SOARESTAWS云计算DevOps架构

InfoQ之前的一篇新闻报道了William Vambenepe的问题“如果云计算的先驱者们都不使用 REST,它对于云计算还重要吗?”报道发表之后,William 作出了进一步的反馈,试图阐明自己最初那篇博文的中心思想,而这中心思想却被别人忽视了,或者说视而不见。他的本意是:对于开发者而言,抛开语言结构(对象或 RPC)底层的交互机制,交互的方法是否通过 REST 实现并不重要。正如 William 所言:

方法(Method)调用就是普通的程序员选择怎样编写一段普通的代码。直接在线上调用远程 API 需要的改变是最少的。RPC 的复杂性从来就不是概念上的,而是存在于在实际操作中的。如何序列化方法调用,如何传输?CORBA、RMI、SOAP 都曾试图解决这个问题,但是没有一个能完美地保持简单并且能在互联网上足够通用。在此过程中,XML-RPC 在一定程度上(不幸地)消亡了。

如他所指出的,AWS 使用了一种非常接近 XML-RPC 的方法。他们在此方法中作出了一些权衡,但是总体来说,AWS 采取了实用的方法,最终产生了一种概念上简单却又强大(并且可用)的方法。然而,很多人似乎仍然不同意这个看法,比如Mike Pearce提到:

我知道我是一个 REST 迷(人们这样称呼那些对 REST 痴迷的人)。但是事实上,Amazon 上并没有证明任何东西,除了傲慢和不尊重开发者之外,什么也没有。

William 试图在最近的博文中解释 Mike 所担心的安歇问题。譬如,其中 Mike 问到:

AWS 使用自己实现的 API 而不采用标准,比如,哦,我还不知道,REST。对于那些不想学习 AWS 交互方式却不得不学习的开发者,这难道不是一种折磨么?

Mike 对此非常肯定,而 William 却不这么看……

我很疑惑。我看见过很多开发者艰难地理解 REST。我却从未见过哪个开发者被 RPC 所吓倒。至于 REST 是一个“标准”的说法,我得去看看规范。不要让我去读博士论文。

William 认为,关键的问题不是 REST 对于云计算的发展是否重要,而是云计算是否已经发展到了那个(开发者或实施者)必须(或应该)作出根本性变革的点。William 的观点是,单个提供商产品带来的 REST 的优势是非常有限的。

云 API 的使用模式可能会发展到那个点,在这个点上遵循 REST 规则所能带来的价值是非常诱人的。我只是认为我们还没有到这个点,而且老实说我也不为此激动。在这个热议的问题变成云服务提供商间交互时应考虑的问题之前,云服务还需要许多功能上的改进。而当共享的 RESTful API 成为最简单的协作 API 时,共享的 RPC API 也一定会变得非常容易管理。到那时,最热的话题可能会变成共享语义的问题,而不再是协议了。

还是有一些不同意 William 的提法的人认为,REST 是用在编程接口背后的,在这个层次上谈论它有必要吗?不过,William 最初的博文中的一个评论者说:

大多数 AWS(或其他云供应商的)用户从来看不到 API。他们是通过语言包、或 Web 客户端应用与这些云服务交互的。所以,真正关心此问题的人是 REST 迷们,以及库开发者们(比如我)。也许有那种差劲到人们无法使用的 API 存在,但是 AWS Query API 远不至于那么糟糕。它相当统一,而且很容易编程。只不过它不是 REST。另外,值得一提的是,并非所有 AWS 服务都是这样的。S3、CloudFront 和 Route53 的 API 都比较倾向于 RESTful。

William 最近博文的整体主题是,好的开发者接口可以隐藏非 REST API 方法,而且还非常有价值,而反过来(译注:REST API 却无很好的开发者接口)并不一定是这样的。好接口与底层 REST 的结合也许是业界最终将会实现的理想世界,但是在现阶段,为了云的成功,既没有必要也没有足够的条件这么做。对于云开发者而言,确保资源语义和编程接口(包括错误处理)的正确性比最好的 RESTful 接口显得更加重要。

如果你的 RPC API 足够统一,以至于可使用 REST API 做其底层模型,那就很好了。

查看英文原文:RPC or REST in the Cloud?
SOARESTAWS云计算DevOps架构