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

　　方法调用就是普通的程序员选择怎样编写一段普通的代码。直接在线上调用远程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的结合也许是业界最终将会实现的理想世界，但是在现阶段，为了云的成功，既没有必要也没有足够的条件这么做。对于云开发者而言，确保资源语义和编程接口（包括错误处理）的正确性比最好的RESTful接口显得更加重要。

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