rest与rpc之间的区别

1，rest

REST是一种架构风格，指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。REST规范把所有内容都视为资源，网络上一切皆资源。

REST并没有创造新的技术，组件或服务，只是使用Web的现有特征和能力。 可以完全通过HTTP协议实现，使用 HTTP 协议处理数据通信。REST架构对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。

2，rpc

RPC（Remote Procedure Call）—远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层，RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

3，rest优缺点
1，优点：耦合性低，兼容性好，提高开发效率，不用关心接口实现细节，相对更规范，更标准，更通用，跨语言支持
2，缺点：性能不如 RPC 高。

4，rpc优缺点
1，优点：
—调用简单，清晰，透明，不用像 rest 一样复杂，就像调用本地方法一样简单。
—高效低延迟，性能高
—自定义协议（让传输报文提及更小）
—性能消耗低，高效的序列化协议可以支持高效的二进制传输
—自带负载均衡
2，缺点：
----耦合性强
例如：
我们为每个微服务定义了各自的 service 抽象接口，并通过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，因此不论开发、测试、集成环境都需要严格的管理版本依赖，才不会出现服务方与调用方的不一致导致应用无法编译成功等一系列问题，以及这也会直接影响本地开发的环境要求，往往一个依赖很多服务的上层应用，每天都要更新很多代码并 install 之后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具，这样的依赖关系会成为开发团队的一大噩梦。
而 REST 接口相比 RPC 更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然 REST 接口也有痛点，因为接口定义过轻，很容易导致定义文档与实际实现不一致导致服务集成时的问题，但是该问题很好解决，只需要通过每个服务整合swagger，让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST 方式的服务依赖要比 RPC 方式的依赖更为灵活。

—无法跨语言，平台敏感
Java 写的 RPC 微服务无法给 Python 调用。需要再实现一层 REST 来对外提供服务
5，rest与rpc选择
RPC 适用于内网服务调用，对外提供服务请走 REST。

IO 密集的服务调用用 RPC，低频服务用 REST

服务调用过于密集与复杂，RPC 就比较适用