1. Overview
1.概述
In this article, we’ll compare REST and gRPC, two architectural styles for web APIs.
在这篇文章中，我们将比较REST和gRPC这两种网络API的架构风格。
2. What Is REST?
2.什么是REST？
REST (Representational State Transfer) is an architectural style that provides guidelines for designing web APIs.
REST（Representational State Transfer）是一种架构风格，为设计网络API提供指导。
It uses standard HTTP 1.1 methods like GET, POST, PUT, and DELETE to work with server-side resources. Additionally, REST APIs provide pre-defined URLs that the client must use to connect with the server.
它使用诸如GET、POST、PUT和DELETE等标准 HTTP 1.1 方法来处理服务器端的资源。此外，REST API提供了预定义的URL，客户端必须使用这些URL来与服务器连接。
3. What Is gRPC?
3.什么是gRPC？
gRPC (Remote Procedure Call) is an open-source data exchange technology developed by Google using the HTTP/2 protocol.
gRPC（远程过程调用）是一种开源的数据交换技术，由Google使用HTTP/2协议开发。
It uses the Protocol Buffers binary format (Protobuf) for data exchange. Also, this architectural style enforces rules that a developer must follow to develop or consume web APIs.
它使用Protocol Buffers 二进制格式（Protobuf）进行数据交换。此外，这种架构风格还强制执行了开发人员在开发或消费Web API时必须遵循的规则。
4. REST vs. gRPC
4.REST与gRPC
4.1. Guidelines vs. Rules
4.1.准则与规则
REST is a set of guidelines for designing web APIs without enforcing anything. On the other hand, gRPC enforces rules by defining a .proto file that must be adhered to by both client and server for data exchange.
REST是一套设计网络API的指南，没有强制执行任何东西。另一方面，gRPC通过定义一个.proto文件来执行规则，客户端和服务器都必须遵守该文件来进行数据交换。
4.2. Underlying HTTP Protocol
4.2.底层的HTTP协议
REST provides a request-response communication model built on the HTTP 1.1 protocol. Therefore, when multiple requests reach the server, it is bound to handle each of them, one at a time.
REST提供了一个建立在HTTP 1.1协议上的请求-响应的通信模型。因此，当多个请求到达服务器时，它必然会逐一处理。
However, gRPC follows a client-response model of communication for designing web APIs that rely on HTTP/2. Hence, gRPC allows streaming communication and serves multiple requests simultaneously. In addition to that, gRPC also supports unary communication similar to REST.
然而，对于设计依赖HTTP/2的Web API，gRPC遵循客户-响应的通信模式。因此，gRPC允许流式通信并同时提供多个请求。除此之外，gRPC还支持类似于REST的单项通信。
4.3. Data Exchange Format
4.3 数据交换格式
REST typically uses JSON and XML formats for data transfer. However, gRPC relies on Protobuf for an exchange of data over the HTTP/2 protocol.
REST通常使用JSON和XML格式进行数据传输。然而，gRPC依靠Protobuf在HTTP/2协议上进行数据交换。
4.4. Serialization vs. Strong Typing
4.4.序列化与强类型化
REST, in most cases, uses JSON or XML that requires serialization and conversion into the target programming language for both client and server, thereby increasing response time and the possibility of errors while parsing the request/response.
在大多数情况下，REST使用JSON或XML，需要对客户端和服务器进行序列化并转换为目标编程语言，从而增加响应时间和解析请求/响应时出现错误的可能性。
However, gRPC provides strongly typed messages automatically converted using the Protobuf exchange format to the chosen programming language.
然而，gRPC提供了强类型的信息，使用Protobuf交换格式自动转换为所选择的编程语言。
4.5. Latency
4.5.延迟
REST utilizing HTTP 1.1 requires a TCP handshake for each request. Hence, REST APIs with HTTP 1.1 can suffer from latency issues.
利用HTTP 1.1的REST需要对每个请求进行TCP握手。因此，采用HTTP 1.1的REST APIs可能会出现延迟问题。
On the other hand, gRPC relies on HTTP/2 protocol, which uses multiplexed streams. Therefore, several clients can send multiple requests simultaneously without establishing a new TCP connection for each one. Also, the server can send push notifications to clients via the established connection.
另一方面，gRPC依赖于HTTP/2协议，它使用多路复用流。因此，几个客户端可以同时发送多个请求，而无需为每个请求建立新的TCP连接。另外，服务器可以通过已建立的连接向客户端发送推送通知。
4.6. Browser Support
4.6.浏览器支持
REST APIs on HTTP 1.1 have universal browser support.
HTTP 1.1上的REST API具有普遍的浏览器支持。
However, gRPC has limited browser support because numerous browsers (usually the older versions) have no mature support for HTTP/2. So, it may require gRPC-web and a proxy layer to perform conversions between HTTP 1.1 and HTTP/2. Therefore, at the moment, gRPC is primarily used for internal services.
然而，gRPC对浏览器的支持有限，因为众多的浏览器（通常是旧版本）对HTTP/2没有成熟的支持。所以，可能需要gRPC-web和一个代理层来进行HTTP 1.1和HTTP/2之间的转换。因此，目前，gRPC主要用于内部服务。
4.7. Code Generation Features
4.7.代码生成功能</b
REST provides no built-in code generation features. However, we can use third-party tools like Swagger or Postman to produce code for API requests.
REST没有提供内置的代码生成功能。然而，我们可以使用第三方工具，如Swagger或Postman来生成API请求的代码。
On the other hand, gRPC, using its protoc compiler, comes with native code generation features, compatible with several programming languages.
另一方面，gRPC使用其protoc编译器，带有本地代码生成功能，与几种编程语言兼容。
5. Conclusion
5.总结
In this article, we compared two architectural styles for APIs, REST and gRPC.
在这篇文章中，我们比较了API的两种架构风格：REST和gRPC。
We conclude that REST is handy in integrating microservices and third-party applications with the core systems.
我们的结论是，REST在将微服务和第三方应用程序与核心系统整合时很方便。
However, gRPC can find its application in various systems like IoT systems that require light-weight message transmission, mobile applications with no browser support, and applications that need multiplexed streams.
然而，gRPC可以在各种系统中找到自己的应用，如需要轻量级消息传输的物联网系统、没有浏览器支持的移动应用以及需要多路流的应用。