导读：API（应用程序编程接口）是使应用程序能够访问服务、操作系统或其他应用程序上的数据或功能。

gRPC 和 REST 是两种软件开发中常见的 API 规范，均用于定义接口的设计。

本文将向各位开发者介绍 gRPC 与 REST 这两种流行的 API 框架，包括它们的优势、局限性和潜在用例进行比较。

什么是 REST API？

REST 是 Representational State Transfer 的缩写。它是一种现代架构风格的实现，依靠一组约束来实现超媒体系统中的数据交换。遵守 REST 约束的系统称为 RESTful。

RESTful Web API 使用 URL 编码的参数来访问使用 HTTP 方法的资源。REST API 框架已在现代 Web 开发中广泛采用，用于构建无状态、可扩展并且可靠的 API。

REST API 如何工作？

在 RESTful API 中，客户端向统一资源定位器发出请求，这会触发一个响应，其负载格式为 JSON、HTML、XML 或其它可接受的数据格式。

客户端请求通常包括以下：

1. 定义要对资源执行操作的 HTTP 方法
2. 描述有关资源请求的信息的标头
3. 资源完整路径
4. 带有客户端数据的可选消息体

REST API 使用 HTTP 的动词：GET、POST、PUT 和 DELETE 来执行资源创建、读取、更新和删除 (CRUD) 操作。

客户端在标头的Accept字段中指定它们可以接收的数据格式。

API 服务器向请求客户端发送数据，包括指定响应正文中使用的消息传输格式的内容类型标头。响应正文还包括一个响应代码，用于通知客户端 API 操作的成功状态。

REST API 的功能

指导 REST API 构建的一些设计约束，包括如下：

1）统一接口

REST API 旨在为微服务之间的交互提供可见性。RESTful API 的设计要求将通用性应用于组件接口，以实现更简单的整体架构和可观察性。

使用以下4个设计约束实现统一的 REST 接口：

1. 每个接口唯一标识 API 客户端和服务器之间交互中涉及的所有资源的能力。
2. 所有资源都应该有统一的表示，API 服务器用它来操纵资源状态。
3. 每个表示都应该有描述客户端/服务器处理消息体的详细信息。
4. 客户端应该只访问初始应用程序 URI，使用动态超链接来访问和操作资源。

2）解耦客户端和服务器端

REST API 通过启用客户端和服务器的独立实现来强制分离关注点。客户端的代码/编程语言和实现可以随时更改，而不会影响服务器的行为方式，反之亦然。

只要客户端和服务器就消息传输格式达成一致，它们之间就能够保持模块化和分隔。客户端和服务器的分隔，通过简化服务器组件的开发，提高了跨平台接口的灵活性。这种解耦还允许每个组件独立开发。

RESTful接口

RESTful API 是无状态的，这意味着服务器不需要知道客户端的状态，反之亦同。

要实现无状态，每个客户端请求都必须包含服务器需要了解的有关资源与操作的所有信息，无需查看先前的消息。

服务器应该用客户端可以完全理解的消息进行响应，而不需要来自先前会话数据包和上下文信息。

无状态消除了因存储以前的请求和响应而导致的服务器负载，这使得 REST API 更可靠、快速且可扩展。

可缓存性

大多数 API 客户端机器和代理均能够缓存服务器的响应数据。

API 服务器响应在呈现给客户端时，需要将自己定义为可缓存或不可缓存，这样可以防止 API 客户端提供老旧的缓存数据来响应下一步的请求。

适当的缓存管理通过部分或完全消除一些缓存，进而来简化客户端-服务器交互，可进一步提高性能与可伸缩性。

分层架构

RESTful 框架强制实施中间层，比如提供共享缓存和负载均衡功能的代理功能。

中间层可以在不更新客户端或服务器端代码的情况下实现软件开发和工具管理。使用分层架构，中间服务器组件可以调用多个其它服务器来创建对请求的响应，而客户端不需要知晓是否直接连接到终端服务器。

按需下载

这是一个可选性约束，它允许服务器通过下载和执行脚本或 Java 小程序形式的代码来临时扩展客户端功能。这减少了应在客户端计算机中预先实现的功能数量。服务器将其中一些功能作为客户端执行的脚本提供。

什么是 gRPC？

gRPC 是一种通用、开源、高性能的远程过程调用 (RPC) 框架，可增强微服务架构的可扩展性和性能。gRPC 使用函数调用在使用不同编程语言构建的微服务中强制执行客户端-服务器通信。

gRPC 依赖于接口定义语言 (IDL) 来就要调用的数据格式和函数建立契约/共识。gRPC API 是使用 RPC 模型和 HTTP 2.0 作为传输协议实现。

gRPC API 的工作原理

gRPC API 依赖协议缓冲区 (protobufs)、流式传输和 HTTP/2 协议进行消息传输。

Protobuf 是一种序列化协议，可以自动生成客户端库和简单定义微服务。API 开发人员在 proto 文件中定义客户端和服务器之间的服务和消息。这些文件由 protoc 编译器加载，它生成用于与远程服务交换消息的客户端和服务器代码。使用协议缓冲区编码的消息比 XML 或 JSON 表示形式小得多，这使得解析占用的 CPU 更少。

gRPC还使用 HTTP/2，它对 RPC 架构进行了大量升级。该协议引入了一个二进制框架层，将数据包分成更小的二进制格式的消息，使它们紧凑且易于移植。HTTP/2 允许使用双向通信模型进行多个并行请求，从而允许在单个通道内实现多个调用。

虽然 HTTP/2 传输协议允许多个同步流，但 gRPC 使用通道扩展了此功能。每个通道都支持通过不同并发连接的多个同步流。通道在特定端口和地址上提供到 API 服务器的简单连接。通道也用于创建客户端存根。

gRPC 之特性

指导构建 gRPC API 的设计约束包括：

面向资源和服务的设计

gRPC 提倡微服务架构设计和系统间松耦合消息交换的理念，以确保分布式对象的高效访问。gRPC API 被建模为资源层次结构，主机被分类为简单资源或集合资源。面向资源的设计强调数据模型而不是在资源上实现的功能；因此，API 通过少量 HTTP 方法公开大量资源。

开源

在设计gRPC API时，开发团队应免费提供所有基本功能供公众使用。所有 API 工件和组件都应作为开源发布，使用促进全球采用的许可条款，而不是阻碍它。

以下是gRPC的接口代码，供各位参考：

syntax = "proto3";
message UrlRequest{
    string req = 1;
}
message UrlResponse{
    int res = 1;
}
service Url{
    rpc CallUrl(UrlRequest) returns (UrlResponse){}
}

分层架构

gRPC 以分层架构实现，基础层是 gRPC 核心层，其它层执行抽象，因此 gRPC API 的开发人员不用担心 RPC 实现的底层细节。

gRPC 使用 Protobuf 生成的代码实现低级通信细节，并生成高级抽象供客户端调用。

与负载不相关

微服务使用不同的编码和消息类型，包括 JSON、XML 和协议缓冲区。

所有 API 实现都必须允许任何微服务使用的消息格式，以便轻松地进行消息交换和有效负载压缩。gRPC 协议和实现还应支持可插入压缩机制，以在更广泛的场景中强制执行高性能消息交换。

流量控制

虽然 HTTP/2 协议已支持跨多个通道快速交换消息，但缺乏流量控制，这样会导致流量瓶颈。

实施流级别和连接级别的流量控制，可以对用于缓冲传输中的消息的内存进行细粒度控制。gRPC 使用WINDOW_UPDATE帧控制，服务器和客户端都在其中公布可以独立接收的数据包数量，对等方遵守规定的8位字节值，确保接收方始终具有传入消息的缓冲能力。

元数据交换

微服务管理功能（例如跟踪和身份验证）依赖于未声明为服务接口一部分的数据交换。API 公开此项数据并确保服务无缝执行，服务声明接口为这些服务处理数据更改不同的速率。

作为 API 的扩展

希望在服务之间实现松耦合交互的开发团队还应考虑使用 API 扩展代替协议。这些 API 主要用来构建服务自检、负载平衡、负载监控和健康检查等扩展的功能。

标准状态代码

客户端有一组特定的方法来响应 API 错误。为了简化错误处理决策，应该对错误和状态代码进行约束和标准化。在更大的部署中，开发人员可以使用元数据交换平台为标准化状态代码提供命名空间。

gRPC 与 REST API——它们有何区别？

gRPC 和 REST API 是用不同的架构风格构建技术，服务于不同的场景。我们根据几种功能和部署方面，比较两种 API 的实现方式。gRPC 和 REST API 都广泛用于现代级、松散耦合以及基于微服务的应用程序部署。

REST API 目标在连接运行内部资源和开放资源的微服务部署，后者常提供大量公共集成。REST API 最适合需要高速 HTTP 消息传输给应用程序。由于 REST API 使用无状态调用，因此它们最适合能够适应工作负载灵活变化的云端应用程序。

当今大多数第三方工具都具有 gRPC API 集成功能，这使 gRPC 成为构建内部系统的理想选择。

gRPC API可用于轻量级微服务连接，这是因为 Protobuf 消息具有高度可移植性。gRPC 处理多路复用和双向通信的能力使它适用于低功耗、低带宽连接中的实时流式传输。

结论

REST 和 gRPC API 设计模型都提供了一种连接松散耦合的方法，并服务于现代软件开发。

本文和各位开发者讨论了指导使用这两种框架开发 API 的设计原则，此外还根据开发方面、优缺点进行了详细比较。

虽然 REST API 主导了云原生和基于微服务的领域开发，但 gRPC API 提供了先天的安全性和可移植性，从而在最近五年内能够迅速流行开来。

作者：场长