作者：行云创新 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。