浅谈 RPC 和 REST: SOAP, gRPC, REST

在一次高盛面试中，被问到了一个问题，SOAP 和 REST 之间的区别是什么？当时东一榔头西一棒槌的答了几条，总感觉很了解的很肤浅。怎么从一个比较全面的角度，去了解 SOAP 和 REST ？最近看了个专栏，文章里相对详细的介绍了他们，加上一些别的搜索和理解，在这里做个总结和梳理。

首先，第一个问题应该是 为什么会将 SOAP 和 REST 进行对比？为了搞清楚这个问题，这篇文章会先介绍 SOAP 基于的模式 RPC，然后依次介绍 RPC 框架 ONC RPC、SOAP、gRPC，最后讲讲 REST ，以及他们的对比。

RPC

在网络世界里，不同机器要怎么互相通信？最基础的方法是基于 TCP/IP 通过 Socket 编程去实现调用方和被调用方。但是 Socket 编程的难度大，需要比较强的专业性，实现又复杂，如果每一次机器之间要通信时，程序员都要手动去处理这么多，这就让新手能做的，变成了要精通网络的老师傅才能完成。有没有什么更好的办法呢？

在 1984 年，Bruce Jay Nelson 发表了奠定基础性的论文 Implementing Remote Procedure Call，定义了机器之间互通这种远程调用的标准。RPC (Remote Procedure Call) 即远程过程调用，有了它，客户端可以像调用本地接口一样调用远程的服务端。

怎么实现远程调用像本地调用一样呢？RPC 模式分为三层，RPCRuntime 负责最底层的网络传输，Stub 处理客户端和服务端约定好的语法、语义的封装和解封装，这些调用远程的细节都被这两层搞定了，用户和服务器这层就只要负责处理业务逻辑，调用本地 Stub 就可以调用远程。

做个比较通俗的类比，你要叫朋友打游戏，如果你和朋友在同一个地方，面对面，你直接跟他说就行了，但是如果你们不在同一个地方，你可以打个电话，你说的和面对面时说的还是一样的，只是通过了电话把这个消息远程的传递给了对方。

RPC 框架要解决的三个问题

基于上述 RPC 模式，一个 RPC 框架基本需要解决 协议约定、网络传输、服务发现 这三个问题。

协议约定问题 指的是怎么规定远程调用的语法，怎么传参数等。用上面的类比，你怎么告诉你的朋友要玩什么游戏？是直接说游戏的名字，王者荣耀，绝地求生，还是说简称，王者，吃鸡，或者用 1 代表王者，2 代表吃鸡，只说 1 或 2。

传输协议问题 指的是在网络发生错误、重传、丢包或者有性能问题时怎么办？用上面的类比，你打电话时，刚说了打什么游戏，但是还没有收到对方回复，电话信号不好断了，这时候怎么处理？

服务发现问题 指的是如果知道服务端有哪些服务可以调用，从哪个端口访问？服务端可能实现多个远程调用，在不同的进程上，随机监听端口，客户端要怎么才能知道这些端口呢？

接下来，对比几个 RPC 框架是如何解决这几个问题的。

ONC RPC

ONC RPC 算是最早 RPC 的一种实现方式，由 Sun 公司开发，在 NFS (Network File S