REST和gRPC的区别

2022-05-07

59

作者:行云创新 ZHOU


REST 主导着现代 API 领域,尤其是在 Web 应用场景。


然而,REST 并不是唯一可用的 API 架构,对于某些场景,gRPC/Protobuf 已占据主导地位。


比较 REST 和 gRPC 的文章俯拾皆是,这里亦不多赘述,只把关键差异述说一二:

1、REST 通常基于 HTTP/1.1 构建,它使用请求-响应通信模型,这意味着无法进行全双工通信。REST 也可以使用 HTTP/2,但它们仍然仅限于请求-响应模型,不能利用 HTTP/2 对双向流式通信的支持,这是浏览器的专属私域。

相比之下,gRPC 使用 HTTP/2,它利用 HTTP/2 支持请求-响应式通信和双向通信。因此,gRPC 可以处理类似于 HTTP/1.1 的请求-响应式交互(客户端发送一个请求,服务器发送一个响应)。同时,客户端还可以支持长连接,每个 gRPC 调用都会打开一个新的 HTTP/2 流——也称双向全双工通信。


2、对于消息的格式,REST 通常使用 json(尽管 REST 也可以承载 Protobuf),GRPC 通常搭配 Protobuf 使用。


3、从客户端编程角度看,REST 服务对 Web 天然友好,但对于微服务之间东西流量的调用,则需要为客户端提供 SDK,否则客户端程序员只能编写大量直接调用 API 的无脑代码,这对客户端开发人员很不友好。

gRPC 恰恰相反,无需提供客户端 SDK,gRPC 可以为多种语言自动生成客户端桩代码,客户端像调用本地函数一样调用 gRPC 服务,但 gRPC 对于 Web 应用不友好,需要通过类似 grpc-gateway(https://github.com/grpc-ecosystem/grpc-gateway)的产品将 gRPC 服务转成 REST 服务,或者网页中的 JavaScript 使用诸如 grpc-web 库(https://github.com/grpc/grpc-web)直接调用 gRPC 服务。


4、从性能角度看,gRPC 数倍优于 REST。


5、从公有云网关易接入性角度看。所有公有云厂商的 API 网关都支持 REST。但支持 gRPC 的比较少。例如,阿里云的 API 网关只支持 REST,腾讯云的 API 网关可以通过插件的方式支持 gRPC,Google Cloud 的 Apigee 原生支持 REST 和 gRPC。这意味着入口侧的南北流量,REST 具有更广泛的适用能力。


无论选 REST 还是 gRPC,面向资源的设计理念都同样适用、都同样重要。


例如,下面的 proto 定义,通过 option (google.api.http) 设置 gRPC 方法和 REST 接口之间的映射关系,借助 protoc 的 protoc-gen-grpc-gateway 插件生成 REST 代码,从而使通过 proto 定义的接口可以同时支持 REST 和 gRPC 两种协议。

该 proto 遵循面向资源的设计理念,抽象出组织(organization)和项目(project),并按 /v1/organizations/{organization}/projects/{project} 的方式组织资源。



面向资源的 API 设计按以下步骤展开:

1、确定资源的类型

2、确定资源之间的关系

3、确定资源的名称

4、确定资源的结构(schema)

5、给资源附加最小的方法集



深入看一下创建 project 的设计:

通过 gRPC 创建 project 的过程是:首先创建 CreateProjectRequest struct 对象,然后调用 CreateProject 方法。


等价的 REST 调用是:创建 CreateProjectRequest json 对象,通过 POST 方法访问 /v1/organizations/{organization}/projects。


技术交流
我们建了一个云原生技术交流群,里面有来自Oracle、Citrix、华为、腾讯等国内外云计算专家,立即扫码,拉你进群。目前已有1000+开发者加入我们......
在云原生时代,行云创新致力于通过赋能开发者,实现企业快速迭代与交付,大幅提升创新效率。
免费试用