REST 与 gRPC：API 之战

REST API 长期以来一直是 Web 编程的支柱。但最近 gRPC 开始蚕食其领土。

Protobuf 与 JSON

REST 和 gRPC 之间最大的区别之一是负载的格式。REST 消息通常包含 JSON。这不是一个严格的要求，理论上您可以发送任何内容作为响应，但实际上整个 REST 生态系统（包括工具、最佳实践和教程）都专注于 JSON。可以肯定地说，除了极少数例外，REST API 接受并返回 JSON。 

另一方面，gRPC 接受并返回Protobuf消息。稍后我将讨论强类型，但仅从性能的角度来看，Protobuf 是一种非常高效且紧凑的格式。另一方面，JSON 是一种文本格式。您可以压缩 JSON，但随后就失去了您可以轻松期望的文本格式的好处。

HTTP/2 与 HTTP 1.1

让我们比较一下 REST 和 gRPC 使用的传输协议。如前所述，REST 在很大程度上依赖于 HTTP（通常是 HTTP 1.1）和请求-响应模型。另一方面，gRPC 使用较新的 HTTP/2 协议。 

HTTP/2 修复了几个困扰 HTTP 1.1 的问题。

HTTP/2 源自 Google 的 SPDY。HTTP/2 协议是二进制的！

大多数实现并没有完全遵循 REST 哲学并且只使用其原则的一个子集。原因是将业务逻辑和操作映射到严格的 REST 世界实际上非常具有挑战性。

gRPC 使用的概念模型是为请求和响应提供具有清晰接口和结构化消息的服务。该模型直接从编程语言概念（如接口、函数、方法和数据结构）转换而来。它还允许 gRPC 为您自动生成客户端库。 

REST 仅支持 HTTP 1.x 中可用的请求-响应模型。但是 gRPC 充分利用了 HTTP/2 的功能，让您不断地流式传输信息。

 

REST 范式不强制要求交换有效负载的任何结构。它通常是 JSON。消费者没有正式的机制来协调请求和响应的格式。必须在服务器端和客户端将 JSON 序列化并转换为目标编程语言。序列化是链中的另一个步骤，它引入了错误的可能性以及性能开销。 

gRPC 服务合约具有强类型消息，这些消息会自动从其 Protobuf 表示转换为您在服务器和客户端上选择的编程语言。

SON 理论上更灵活，因为您可以发送动态数据，而不必遵守严格的结构。

浏览器中对 gRPC 的支持还不够成熟。今天，gRPC 主要用于不直接向外界公开的内部服务。

 

在微服务领域，gRPC 很快就会占据主导地位。性能优势和易于开发的优势不容错过。但是，请不要误会，REST 仍然会存在很长时间。由于公开的 API 和向后兼容的原因，它仍然表现出色。