什么时候RPC-ish方法比REST更合适？

Question

在看了Steve的这个论休息、再利用与宿命演讲之后，我想知道对于(XML-)RPC-ish的设置来说，绿地项目中是否有业务案例，其余的都无法以更好的方式解决。

他提到了几个RPC问题：

• 关注语言(使分布式系统与语言相适应，而不是相反)
• “让它看起来是本地的”(并将失败和延迟作为异常而不是规则来处理)
• 意图是独立于语言，但仍然有跨语言的“函数调用”作为主要成分。
• IDL样板
• 类型安全错觉
• 再来几个..。

为了戏剧化一点，一些针对RPC和REST的Google即时结果：

Answer 1

一般来说，RPC提供的语言集成远远多于REST。正如您所提到的，这在规模、错误处理、类型安全性等方面存在许多问题，特别是当单个分布式系统涉及多个主机，运行用多种语言编写的代码时。但是，在编写了同时使用RPC、REST甚至两者的业务系统之后，我发现在某些情况下选择RPC而不是REST是有很好的理由的。

下面是我发现RPC更适合的情况：

• 紧密耦合。系统的(分布式)组件设计为协同工作，而更改一个组件可能会影响所有其他组件。今后，这些组件不太可能适应于与其他系统的通信。
• 可靠的通讯。这些组件将完全在同一台主机上或在不太可能出现延迟问题、数据包丢失等的网络上相互通信。(这仍然意味着您需要设计您的系统来处理这些情况。)
• 统一的语言。所有(或大部分)组件都将用一种语言编写。将来不太可能增加用不同语言编写的其他组件。

关于IDL，在REST系统中，您还必须编写代码，将REST请求和响应中的数据转换为所使用的任何内部数据表示形式。IDL源代码(有很好的注释)也可以作为接口的文档，它必须为REST单独编写和维护。

当您希望构建更大系统的一个组件时，通常会出现上述三项。根据我的经验，这些组件通常是这样的:它们的子系统需要能够独立地失败，而不是导致其他子系统或整个组件的全部故障。许多系统都是用Erlang编写的，以实现这些目标，在某些情况下，Erlang可能是一个更好的选择，而不是用另一种语言编写系统并使用RPC来获得这些好处。

与大多数工程问题一样，对于进程间通信问题没有一个单一的解决方案.您需要查看您正在设计的系统，并为您的用例做出最佳选择。

Answer 2

REST的一些主要优点是，当产品在数据中心上扩展时，您正在进行高可用性和负载平衡。

然而，考虑一个规模较小的项目。需要一个每小时有几百个请求的网络服务吗？WCF处理所有的运输问题。具有通过网络发送对象的方便接口，并允许配置、加密和认证网络连接，只使用application.config文件进行零编程。

Answer 3

你真的可以两者兼得。像Grails的RestRPC这样的插件提供了注释，它将拦截对方法的调用并重新处理它们，同时允许您拥有任意数量的方法(这将非常类似于RPC)。