远程过程调用（RPC）问题

• Enterprise JavaBeans（EJB）和Java的远程方法调用（RMI）仅限于Java
• 分布式组件对象模型（DCOM）仅限于Microsoft平台
• 公共对象请求代理体系结构（CORBA）过于复杂，不提供前向或后向兼容性

所有这些都是基于诞生自1970s的远程过程调用（RPC）思想。 RPC模型试图向远程网络服务发出请求，看起来与在同一进程中调用编程语言的方法相同（这种抽象称为位置透明）。尽管RPC起初看起来很方便，但这种方法根本上是有缺陷的。网络请求与本地函数调用很不同：

• 本地方法调用可预测，且成功或失败仅取决于控制的参数。网络请求不可预知：由于网络问题，请求或响应可能会丢失，或远程计算机可能很慢或不可用。网络问题很常见，所以必须做好应对，如重试失败的请求
• 本地方法调用要么返回一个结果，要么抛出一个异常或永远不返回（因为进入无限循环或进程崩溃）。网络请求有另一个可能结果：由于超时，返回时可能没有结果。此时不知发生什么：若未收到远程服务响应，就无法知道请求是否成功
• 若重试失败请求，可能会发生请求实际已完成，只有响应丢失。此时，重试将导致该操作被执行多次，除非在协议中引入除重（ 幂等性）机制。本地方法调用就没这问题
• 每次调用本地方法时，一般需执行大致相同的时间。网络请求比函数方法慢得多，且其延迟也有很大变化：好时可能不到1ms内完成，网络拥塞或远程服务超载时，可能需几s才完成
• 调用本地方法，可高效地将引用传递给本机内存中的对象。当发出网络请求时，所有这些参数都需编码成可通过网络发送的字节序列。若参数是数字或字符串这样基本类型倒没啥，但当是较大对象就会变成问题
• 客户端和服务可以用不同编程语言实现，所以RPC框架必须将数据类型从一种语言转成另一种语言。因为不是所有语言都有相同类型。用单一语言编写的单个进程中则不存在该问题

这些都意味着尝试使远程服务看起来像编程语言中的本地对象毫无意义，因为这是根本不同的两件事情。 REST部分迷人的在于，它并不试图隐藏它是网络协议的事实（尽管这似乎并没有阻止人们在REST之上构建RPC库）。