HTTP/Restful/RPC

一句话概括Restful

Restful是服务端架构风格，用URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作。

关系

引自：三种关系

1、HTTP和RPC同一级别，还是被RPC包含？

2、Restful也属于RPC么？

对于以上两点，我画图来一一说明。

上图是一个比较完整的关系图，这时我们发现HTTP（图中蓝色框）出现了两次。其中一个是和RPC并列的，都是跨应用调用方法的解决方案；另一个则是被RPC包含的，是RPC通信过程的可选协议之一。
因此，第一个问题的答案是都对。看指的是哪一个蓝色框。从题主的提问看，既然题主在纠结这两者，应该是指与RPC并列的蓝色框。
第二个问题是在问远程过程调用（红色框）是不是包含了Restful（黄色框），这种理解的关键在于对RPC的理解。
RPC字面理解是远程过程调用，即在一个应用中调用另一个应用的方法。那Restful是满足的，通过它可以实现在一个应用中调用另一个应用的方法。
但是，上述理解使得RPC的定义过于宽泛。RPC通常特指在一个应用中调用另一个应用的接口（**本人理解成interface**）而实现的远程调用，即红色框所指的范围。这样，RPC是不包含Restful的。
因此，第二个问题的答案是Restful不属于RPC，除非对RPC有着非常规的宽泛理解。

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 就比较适用
一、rest：

REST 不是一种协议，它是一种架构。大部分REST的实现中使用了RPC的机制，大致由三部分组成：

1、method：动词（get、post之类的）

2、Host：URI（统一资源标识），服务器，端口

3、Path：名词（路径，服务器里面的某个东西）路径的结尾是资源的形态（如html、text、image、pdf等）

即、对 host 里面的某个 Path 里面的东西做一些 get 或 post 操作。

二、rpc：

RPC 是一种技术思想而非一种规范或协议，通常的调用过程为：把函数序列化，远端收到后，再把函数反序列化，完成函数调用。

三、rest 和 rpc 的区别

REST：想对服务器里面的资源进行操作，下载服务器端的当前状态，修改之后将最终用户所期待的状态发送给服务器，服务器按照客户的期待进行修改。修改代码在客户端，所以REST风格客户端逻辑相比客户端更复杂。自由度更大一些，但因此造成失误的可能性也大一些。传输层基于HTTP，相比于TCP，多了一层协议。但基于HTTP传输，可以穿越防火墙，适合组织内向组织外提供服务。

RPC：想对服务器里面的资源进行修改，首先需要了解服务器中各个接口都是干啥的，然后把相关参数传给服务器提供的接口，让服务器自己去执行修改。修改代码在服务端，所以RPC服务端逻辑更复杂些，服务器会有很大的工作量，但分工明确，不容易造成失误。可以基于TCP或HTTP，如果基于TCP，将少一层协议。

四、例子

如果想对服务端数据库里面的一个数进行 加1、减1 这两种操作。两种不同的实现方式如下：

REST中：服务端只要留一个接口就可以了，作用是更改数据库里面的数（不管它是加了还是减了），然后客户端有两个函数，分别进行加操作和减操作，但客户端操作完都提交给同一个服务端函数，然后更改数据库。

RPC中：服务端应该留两个接口函数，分别对应加1和减1操作，当客户端需要进行修改时，先要弄明白哪个做加1操作、哪个做减1操作，然后入参调用，让服务端进行加1，减1操作后更改数据库。

五、目前流行架构