1 REST
REST 不是一种协议，它是一种架构。大部分REST的实现中使用了RPC的机制，大致由三部分组成：
- method：动词（GET、POST、PUT、DELETE之类的）
- Host：URI（统一资源标识），服务器ip，端口
- Path：名词（路径，服务器里面的某个东西）路径的结尾是资源的形态（如html、text、image、pdf等）
即对 Host 中的某个 Path对应的资源做method操作。
2 RPC
RPC 是一种技术思想而非一种规范或协议，通常的调用过程为：
1）客户端把函数序列化；
2）远端服务收到后，再把函数反序列化，完成函数调用。
就是像调用本地方法一样调用远程方法，通信协议大多采用二进制方式，长链接，效率更高。
2.1 组件
RPC架构里包含如下4个组件:
- 客户端(Client)：服务调用方
- 客户端存根(Client Stub)：存放服务端地址信息，将客户端的请求参数打包成网络消息，再通过网络发送给服务方
- 服务端存根(Server Stub)：接受客户端发送过来的消息并解包，再调用本地服务
- 服务端(Server)：真正的服务提供者。
2.2 实现过程
RPC具体实现步骤如下：
1）服务调用方（client）(客户端)以本地调用方式调用服务；
2）client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体，比如在Java里就是序列化的过程；
3）client stub找到服务地址，并将消息通过网络发送到服务端；
4）server stub收到消息后进行解码,比如在Java里就是反序列化的过程；
5）server stub根据解码结果调用本地的服务；
6）本地服务执行处理逻辑；
7）本地服务将结果返回给server stub；
8）server stub将返回结果打包成消息，Java里的序列化；
9）server stub将打包后的消息通过网络并发送至消费方
10）client stub接收到消息，并进行解码, Java里的反序列化；
11）服务调用方（client）得到最终结果。
RPC框架的目标就是把2-10步封装起来，把调用、编码/解码的过程封装起来，让用户像调用本地服务一样的调用远程服务。
3 REST和 RPC的区别
3.1 REST
如需对服务资源进行操作，需要先确认服务端的当前状态，修改之后将最终用户所期待的状态发送给服务端，服务端按照客户的期待进行修改。
修改代码在客户端，所以REST风格客户端逻辑相比客户端更复杂。自由度更大一些，但因此造成失误的可能性也大一些。
传输层基于HTTP，相比于TCP，多了一层协议。但基于HTTP传输，可以穿越防火墙，适合组织内向组织外提供服务,此外REST的接口的安全性相比RPC更高。
3.2 RPC
如需对服务里面的资源进行修改，首先需要了解服务端中各个接口的功能和调用方式，然后把相关参数传给服务端提供的接口，让服务端自己去执行修改。
修改代码在服务端，所以RPC服务端逻辑更复杂些，服务端会有很大的工作量，但分工明确，不容易造成失误。
可以基于TCP或HTTP，如果基于TCP，将少一层协议。
3.3 使用场景
REST调用及测试都很方便，RPC就显得有点繁琐，但是RPC的效率是毋庸置疑的，所以建议在多系统之间的内部调用采用RPC。对外提供的服务，Rest更加合适。
| 对比项 | REST | RPC |
| 范式 | 面向资源的范式，它强调对 URI 所代表的资源进行操作。 | 面向方法的范式，强调远程调用函数，客户端和服务器之间传递的数据是通过序列化方法的参数和返回值来实现的 |
| 通信协议 | HTTP | 一般使用TCP |
| 数据格式 | REST 使用 JSON、XML 等文本格式传输数据，这些格式易于阅读和解析 | RPC 通常使用二进制格式传输数据，如 Protobuf 和 MessagePack 等 |
| 编程模型 | REST 是基于 HTTP 协议的，只要能够发送 HTTP 请求和解析 HTTP 响应的语言都可以使用 REST | RPC 支持多种编程语言和平台，如 Java、C++、Python |
| 性能 | 低 | 高 |
| 灵活度 | 高 | 低 |
| 使用场景 |
|
|
3.4 案例
如果想对服务端数据库里面的一个数进行加1、减1 这两种操作。两种不同的实现方式如下：
- REST：服务端只需要一个接口，作用是更改数据库里面的数（不管是加了还是减了），然后客户端有两个函数，分别进行加操作和减操作，但客户端操作完都提交给同一个服务端函数，然后更改数据库。
- RPC中：服务端应该留两个接口函数，分别对应加1和减1操作，当客户端需要进行修改时，先要弄明白哪个做加1操作、哪个做减1操作，然后入参调用，让服务端进行加1，减1操作后更改数据库。
3.5 优缺点
3.5.1 REST优缺点
优点：耦合性低，兼容性好，提高开发效率，不用关心接口实现细节，相对更规范，更标准，更通用，跨语言支持
缺点：性能不如 RPC 高。
3.5.2 RPC优缺点
优点：
- 调用简单，清晰，透明，不用像 rest 一样复杂，就像调用本地方法一样简单。
- 高效低延迟，性能高
- 自定义协议（让传输报文提及更小）
- 性能消耗低，高效的序列化协议可以支持高效的二进制传输
- 自带负载均衡
缺点：
- 耦合性强，例如：开发人员为每个微服务定义了各自的 service 抽象接口，并通过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，因此不论开发、测试、集成环境都需要严格的管理版本依赖，才不会出现服务方与调用方的不一致导致应用无法编译成功等一系列问题，以及这也会直接影响本地开发的环境要求，往往一个依赖很多服务的上层应用，每天都要更新很多代码并 install 之后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具，这样的依赖关系会成为开发团队的一大噩梦。而 REST 接口相比 RPC 更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然 REST 接口也有痛点，因为接口定义过轻，很容易导致定义文档与实际实现不一致导致服务集成时的问题，但是该问题很好解决，只需要通过每个服务整合swagger，让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST 方式的服务依赖要比 RPC 方式的依赖更为灵活。
- 无法跨语言，平台敏感，Java 写的 RPC 微服务无法给 Python 调用。需要再实现一层 REST 来对外提供服务
