云 API 纷争又起：RPC 还是 REST

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?