如果您非常熟悉 API，您就会知道 REST API 是使用的主要 API，尤其是在微服务及其应用程序方面。gRPC 是使用 HTTP/2 的高性能、二进制和强类型协议，而 REST 是使用 HTTP 和 JSON/XML 的更简单、基于文本和无状态的协议。gRPC 更高效，适合复杂的微服务和实时应用程序，而 REST 更广泛地采用，并且更易于用于基本 API。

无论您是想弄清楚“gRPC”的含义，还是考虑将 gRPC 作为下一个开发项目的 REST API 的替代方案，本指南都将帮助您理解。您将了解 gRPC 是什么、人们为什么使用它以及 gRCP API 与 RESTful API 的比较。

以下是 gRPC 和 REST 之间的主要区别：

1. 协议：gRPC 使用 HTTP/2 进行传输，而 REST 通常使用 HTTP/1.1。
2. 数据格式：gRPC 使用 Protocol Buffer 进行序列化，而 REST 通常使用 JSON 或 XML。
3. API设计：gRPC基于RPC（远程过程调用）范式，而REST则遵循表述性状态传输模型的架构约束。
4. 流式传输：gRPC 支持双向流式传输，而 REST 仅限于请求-响应通信模式。

目录：

• REST 与 gRPC 相比有何优势？
• 了解 API 中的架构风格
• 什么是基于微服务的应用程序？
• 了解 REST API
• 了解 RPC API
• gRPC API 的工作原理
• 什么时候应该使用 REST 和 gRPC？
• 如何更快地构建 API
• 常见问题：gRPC 与 REST

需要 API 吗？您是否知道可以使用 DreamFactory 在几分钟内生成功能齐全、有文档记录且安全的 REST API？注册我们的14 天免费托管试用版以了解操作方法！我们的导览将向您展示如何使用作为试用的一部分提供给您的示例 MySQL 数据库来创建 API！

立即创建您的 REST API

REST 与 gRPC 相比有何优势？

REST 更受欢迎有充分的理由吗？如果您想了解 REST 和 gRPC，在我们深入探讨它们之间的差异之前，您需要了解一些事情。

API（或应用程序编程接口）提供允许应用程序相互通信和交互的规则和定义。API 定义了一个应用程序可以向另一个应用程序发出的调用和请求的类型、如何发出这些请求、要使用的数据格式以及客户端必须遵循的约定。

本质上，API 通过连接多个功能使应用程序可以在更大的系统中使用。这些功能可以相互协作和交互，并且您可以添加越来越多的功能或微服务。

即使微服务是用不同的编程语言编写并在不同的平台上运行，它们也可以一起工作。就其本质而言，API 被设计为兼容的。它们创建微服务之间所需的连接。您可以了解有关使用DreamFactory创建您自己的 API 的更多信息。

了解 API 中的架构风格

REST API 和 gRPC API 指的是构建 API 的不同架构风格。虽然它们连接微服务或应用程序，但它们有不同的方法来实现这一点。

每种架构风格都设计用于特定情况，因此您需要根据您的需求做出决定。

什么是 REST API？

REST 是构建 API 最常用的架构风格。它对于基于 Web 的应用程序和基于微服务的基础设施特别有用。

REST API 使用 JSON，这是一种基于文本的人类可读格式，适用于多个平台。虽然不是唯一可与 REST API 一起使用的格式，但由于其简单性而最常用。

JSON 用于在微服务和互联网应用程序之间建立更好的链接，帮助它们相互通信。这些是 REST API 最常用的案例，您会发现它们无处不在。REST 可以使用 JSON 在微服务之间根据需要接收和发送消息。

什么是 gRPC？

gRPC作为一种开源的RPC架构，创建了微服务之间的高速通信。它最初是由谷歌开发的，旨在改善通信。

开发人员如何使用 gRPC？借助 API，这种 API 架构允许使用不同编程语言创建的多个函数协同工作。gRPC 使用 Protobuf（协议缓冲区）消息传递格式，这是一种高度封装、高效的消息传递格式，用于序列化结构化数据。对于一组特定的用例，gRPC API 可以作为 REST API 的更有效替代方案（稍后会详细介绍）。

下面是一个比较 REST API 和 gRPC 基础知识的简单矩阵：

一般来说，API 使得创建基于微服务的应用程序成为可能，而不是仅仅依赖于缓慢的单体应用程序。有必要使用API?来创建多个功能之间的链接，以便整个项目能够无缝运行。您使用哪个 API 将取决于它是否是特殊情况。

什么是基于微服务的应用程序？

基于微服务的应用程序克服了传统单体应用程序的最大限制。整体应用程序将其所有服务和功能的编程包含在单个不可分割的代码库中，该代码库管理应用程序的所有服务和功能。许多公司从单体应用程序开始，因为它通常是最简单的选择。

随着开发人员在现有框架之上添加新服务和功能，修改、升级和扩展应用程序变得越来越困难。更改应用程序的一部分可能会对其他区域产生负面影响。在多次扩展、更新和更改单体之后，代码库最终变得如此相互依赖且难以理解，以至于有必要从头开始重新设计整个系统。因此，越来越多的公司在传统的整体系统之外开展工作。他们更喜欢使用微服务。

基于微服务的应用架构解决了万物互联的问题。该架构风格将整体分解为其组件服务，并将每个组件作为自治应用程序运行。这些组件称为微服务。然后，这些单独的微服务使用 API 相互交互。这些通过 API 连接的微服务组共同构成了更大的应用程序架构。

由于 API 允许自主运行的微服务相互连接，因此 API 允许您实现可插入的、基于组件的系统。即使微服务是用不同的编程语言或在不同的平台上设计和编码的，它们也可以一起工作和通信。这使得它们非常有用，并且还确保您可以使用适合您需求的微服务。

升级单个微服务变得更快更容易，因为对自主运行的服务所做的更改对整个系统的影响较小。扩展也更容易、更高效。可以根据使用需求将资源转移到需要它们的微服务。此外，如果一项微服务出现故障或速度减慢，则不太可能导致整个基础设施瘫痪。所有这些都转化为更高效、更有弹性、可扩展且灵活的系统，而 API 使这一切成为可能。

微服务在世界各地被大公司和小型企业所使用。如果您知道 Netflix、WordPress、Uber 和 Amazon 等公司都在使用它们，您不会感到惊讶。微服务具有几乎无限扩展并提供高质量服务和功能的能力，因此很有意义。

您可能遇到过被要求获取 API 以在您的网站或博客上使用的情况。它们可用于连接小型企业和功能，以及大型企业和功能。它们可以根据需要进行缩放。

在起步时，公司需要考虑未来。他们必须考虑一年或五年后需要哪些申请。当业务增长时可能需要哪些选择？入门实际上只是一个开始，从一个不会与您的公司一起成长的系统开始是短视的。相反，最好着眼于微服务，并从一开始就考虑到这一点来设置一切。该过程可能需要更长的时间，但随着时间的推移，系统会更好地为您服务。这也导致多年来花费的时间和金钱更少。

最广泛使用的 API 架构风格是 REST API。但是，还有 RPC API 和gRPC API。在接下来的部分中，我们将了解这些 API 的比较。

了解 REST API

REST（表述性状态传输）描述了一种客户端-服务器组织，其中后端数据通过 JSON 或 XML 消息传递格式提供给客户端。根据 Roy Fielding 的说法，当 API 满足以下约束时，它就符合“RESTful”标准：

• 统一的接口： API 必须向 API 使用者公开特定的应用程序资源。
• 客户端-服务器独立性：客户端和服务器独立运行。客户端只会知道指向应用程序资源的 URI。这些通常发布在 API 文档中。
• 无状态：服务器不保存与客户端请求有关的任何数据。客户端将此“状态数据”保存在其末端（通过缓存）。
• 可缓存： API 公开的应用程序资源需要可缓存。
• 分层：架构是分层的，允许不同的组件维护在不同的服务器上。
• 按需代码 (COD)：这是唯一可选的 REST 约束。这允许客户端接收服务器的可执行代码作为响应。换句话说，服务器决定如何完成特定的事情。

还需要注意的是，REST API 几乎在所有情况下都使用 HTTP 协议。这是 Web 应用程序或互连微服务最常用的格式。一旦 REST API 在 Web 服务中公开可用，客户端就可以将每个组件用作资源。通常，可以通过通用接口访问资源，该接口接受不同的 HTTP 命令，例如 GET、POST、DELETE 和 PUT。

您可能已经在 Facebook 和 Mailchimp 等网站上看到过 REST API 的实际应用。这两个应用程序使用的 API 架构有所不同，但它们仍然相似。其他使用 REST 的网站包括 Spotify、Netflix 和 Uber。

创建 REST API 是确保您准确获得所需内容的绝佳方法，而且我们的方法使这一切变得简单。通过尝试DreamFactory可以避免开发自己的 API 时出现的一些问题。

了解 RPC API

RPC 或远程过程调用最初创建于 1970 年代，被认为是 REST 的前身。虽然您当然可以在不了解历史的情况下使用 REST API，但您可能希望更多地了解这些旧方法的工作原理。RPC 在远程服务器上引发函数，但与较新的 API 不同，它使用特定的格式，并且必须接收相同格式的响应。

RPC API 的基本概念与 REST API 类似。RPC API 定义了客户端可以用来与之交互的交互规则和方法。客户端提交使用“参数”的调用来调用这些方法。然而，该技术可以在带有 RPC API 的 URL 中找到。调用方法的参数可以在查询字符串中找到。为了说明这一点，以下是 RPC API 请求与 REST API 请求的比较：

• RPC： RPC API 请求可能使用 POST /deleteResource 并具有一个表示 {“id”: 3 } 的查询字符串
• REST： REST API 请求会将此请求写入 DELETE /resource/2。

RPC 被认为有些过时了，现在您很少会发现它在使用。在大多数情况下，它已被替换。其他两个选项已经迅速取代了任何与 RPC 一起使用的选项。

gRPC API 的工作原理

gRPC作为 RPC 架构的变体， 由 Google 于 2015 年创建，旨在加速微服务和其他需要交互的系统之间的数据传输。由于多种原因，此 API 架构与以前的 API 有所不同。

首先，gRPC使用不同的格式。该 API 不使用 JSON，而是使用 Protobuf。Protobuf 也是由 Google 开发的，是语言中立和平台中立的。它与 XML 类似，但被认为更高效。

这个API结构也使用HTTP2，而不是原来的HTTP1，并且比原来的RPC要快得多。这意味着它更容易实现，因为它传输消息的速度比以前的版本快 10 倍。对于较大的应用程序，这使得管理事物的通信方面成为可能，尽管在实现 API 时它比 REST 慢。

最后，gRPC使用自己的私有代码生成而不是 Swagger 进行通信。如果您想了解更多有关所有这些的信息，请继续阅读。

1.Protobuf代替JSON/XML

REST API 和 RPC API 常用 JSON 和 XML 消息传递格式进行消息传递。虽然 JSON 是最受欢迎的选择，但由于其灵活性和语言/平台中立性，它在使用时可能会很卡顿且缓慢。

与 REST 和 RPC 相比，gRPC 通过使用Protobuf（协议缓冲区）消息传递格式克服了与速度和重量相关的问题，并在发送消息时提供了更高的效率。以下是关于 Protobuf 的一些细节：

• 与平台和语言无关，例如 JSON
• 序列化和反序列化结构化数据以通过二进制进行通信
• 作为一种高度压缩的格式，它无法达到 JSON 的人类可读性水平
• 通过消除 JSON 管理的许多职责来加速数据传输，以便它可以严格专注于序列化和反序列化数据
• 数据传输速度更快，因为 Protobuf 减小了消息的大小并作为轻量级消息传递格式

使用 Protobuf，与gRPC API相关的一些缺点大大减少。

2. 基于 HTTP 2 而不是 HTTP 1.1 构建

gRPC提高效率的另一种方法是使用 HTTP 2 协议。HTTP 指的是超文本传输??协议，自 1989 年以来一直存在，是整个互联网上的通信方法。

REST API 使用 HTTP 1.1，而gRPC API 使用 HTTP 2。这两种协议之间存在一些显着差异。

HTTP 1.1：该协议于 1997 年发布，通常被认为是万维网上通信的标准。本质上，它在计算机和网络服务器之间中继信息，网络服务器可以是本地的也可以是远程的。客户端计算机发送基于文本的请求并返回资源。在 WWW 的常用用法中，这意味着 HTML 页面或 PDF 文档。

HTTP 2：该协议于 2015 年发布，大多数现代浏览器都使用它。Chrome、Internet Explorer 和 Safari 都使用 HTTP 2，这意味着它已被广泛采用。但是，它的工作方式与 HTTP 1.1 不同。HTTP 2 使用二进制格式封装，而不是以纯文本格式维护所有内容。这加快了整个过程并允许更广泛的数据传输选项。

简而言之，HTTP 2 更快、更高效，并通过使用多路复用减少网络延迟。

使用 HTTP 2，gRPC提供三种类型的流式传输：

• 服务器端：客户端向服务器发送请求消息。服务器将响应流返回给客户端。完成响应后，服务器会发送一条状态消息（在某??些情况下，还会发送尾随元数据），从而完成该过程。收到所有响应后，客户端完成该过程。
• 客户端：客户端向服务器发送请求消息流。服务器向客户端返回一个响应。它（通常）在收到来自客户端的所有请求和状态消息（有时还有尾随元数据）后发送响应。
• 双向：客户端和服务器不按特定顺序相互传输数据。客户端是发起这种双向流的客户端。客户端也结束连接。

3. 内置代码生成而不是使用第三方工具

乍一看，第三方集成（例如 REST API 的使用）似乎是个好主意。然而，它可能有一些缺点，并且许多人更喜欢gRPC的本机代码生成。

gRPC API 使用自己的Protoc 编译器，允许您创建自己的代码。它适用于多种语言，并且可以在多语言环境中使用。这是指在不同平台上运行并以多种语言编码的微服务组。

REST API 缺乏这种本机代码生成，必须使用外部工具。通常，它与 Swagger 配合使用以确保创建多种语言。对于许多人来说，这被认为是一个缺点，但 REST 仍然很受欢迎。

4. 消息传输速度提高7至10倍

根据Ruwan Fernando 发布的被广泛引用的测试，他发现gRPC API 连接的速度比 REST API 连接的速度更高。事实上，他报告说它们的速度快了 7 到 10 倍：

“在接收数据时，gRPC 比 REST 快大约 7 倍；在发送特定负载的数据时，gRPC 比 REST 快大约 10 倍。这主要是由于 Protocol Buffers 的紧密封装以及 gRPC 对 HTTP/2 的使用。”

5. 实施速度比 REST 慢

尽管在消息传输速度方面有优势，但这种类型的 API 实现比 REST API 实现慢得多。据 Ruan Fernando 介绍，实现一个简单的 gRPC 服务大约需要 45 分钟。实施 Web 或 REST API 只需大约 10 分钟。在为您的系统选择最佳选项时，这是一个重要因素。

延迟的原因是第三方工具尚未对该 API 结构提供太多支持。由于 gRPC 尚未广泛流行，因此它仍然缺乏应有的支持。整个过程不但没有在几分钟内完美地集成，反而变得很拖延。

以下是费尔南多关于实施时间的 说法：

“我不得不花费大约 45 分钟来实现这个简单的 gRPC服务，而我只花了大约 10 分钟来构建 WebAPI。这主要是由于 REST 很久以前就成为主流，并且大多数主要框架（即 ASP.NET Core MVC）都具有内置支持来快速启动此类服务（通过约定和模式）。”

什么时候应该使用 REST 和 gRPC？

有两个选项可供选择，您应该使用哪个 API？这实际上取决于您正在从事的项目以及您需要 API 来做什么。REST 仍然是最常见的，但这并不意味着它应该被自动使用。

什么时候应该使用 RESTAPI？

什么时候应该使用 REST API？一般来说，它们最常用于构建基于微服务的基础设施。每当您计划构建需要连接微服务的应用程序或更大的计算机系统时，REST 都是最常见的选择。

REST API 也最适合需要速度的系统。如果你需要标准化的HTTP协议、高速迭代、多语言微服务连接，那么REST应该是你的主要选择。它们还具有第三方工具的普遍支持，因此非常适合从应用程序到网络服务的所有内容。

什么时候应该使用 gRPC？

至于 gRPC，大多数第三方工具仍然缺乏内置的兼容性功能。因此，它主要用于构建内部系统，即对外部用户关闭的基础设施。考虑到这一点，gRPC API 在以下情况下可能会有所帮助：

• 微服务连接： gRPC 的 低延迟和高速吞吐量通信使其特别适用于连接由轻量级微服务组成的架构，其中消息传输的效率至关重要。
• 多语言系统：凭借对多种开发语言的本机代码生成支持，gRPC 在管理多语言环境中的连接时非常出色。
• 实时流：当需要实时通信时，gRPC 管理双向流的能力允许您的系统实时发送和接收消息，而无需等待一元客户端响应通信。
• 低功耗、低带宽网络：gRPC 使用序列化 Protobuf 消息，为带宽受限的低功耗网络提供轻量级消息传递、更高的效率和速度（尤其是与 JSON 相比）。物联网就是此类网络的一个例子，可以从此类 API 中受益。

您可以使用专门用于此目的的平台构建自己的 API。在这里了解更多信息。

如何记录您的 API

无论您使用 REST API 还是gRPC，文档都是必不可少的。尽管 REST 更流行，但它仍然需要说明和信息。客户必须了解如何使用它并能够配置所有内容以添加到他们的应用程序中。一个很好的例子就是向 WordPress 添加功能。附加的微服务可以提供从跟踪订单到提供多种语言翻译以及介于两者之间的所有功能。您的文档应该足够清晰，以便任何客户都可以使用它并快速设置您的 API。

应该包括什么？用户必须了解以下几点：

• API 的相关端点是什么？
• 使用什么术语以及如何定义？
• 提供端点的示例请求。
• 有关如何集成各种编程语言的信息。
• 共享各种错误消息和状态代码，以便于参考和故障排除。
• 一步一步来，即使看起来过于简单。

应包含有关如何使用 API以及如何将其添加到程序中的教程。许多人喜欢看步骤视频，但您也可以将其写下来以方便参考。API 文档应该由真正了解系统并且能够清晰简单地编写的人创建。

通常，文档可能会变得枯燥且技术性强，因此您可能需要仔细检查它以确保每个人都能够使用它。这可能需要在需要时使用外行术语。您还应该考虑使用编号步骤，以便客户更容易遵循。

如果您通过自己编码从头开始创建 API，则创建文档通常会更加复杂。您将完全沉浸在技术方面的事情中，并且可能很难向客户解释。相反，应关注最终用户以及他们需要了解的内容。他们不一定需要知道事物是如何工作的，只需要知道如何使用它们即可。

如果您使用外部平台来创建 API，您会发现创建与之配套的文档会更快、更容易。

如何更快地构建 API

REST API 开发对于开发基于微服务的现代应用程序架构至关重要。然而，如果您手动编写一个简单的 REST API，则可能需要数周的时间 — 这意味着高昂的劳动力成本和项目的延迟。由于需要花费大量时间，您将需要寻找替代方案。例如，DreamFactory IPaaS 和 API 网关等某些平台可以提供帮助。

DreamFactory 平台最有用的功能之一是它能够自动生成 REST API。借助 DreamFactory，您可以生成完全 Swagger 记录的 REST API，以在几分钟内连接几乎任何数据库或服务。

这些平台旨在让您更简单、更快速地创建 API。无需编码，无需学习一行代码即可完成所需的一切。

需要 API 吗？您是否知道可以使用 DreamFactory 在几分钟内生成功能齐全、有文档记录且安全的 REST API？注册我们的14 天免费托管试用版以了解操作方法！我们的导览将向您展示如何使用作为试用的一部分提供给您的示例 MySQL 数据库来创建 API！

立即创建您的 REST API

关于 REST 与 gRPC 的最终想法

有些人认为gRPC是未来的 API。然而，我们还需要一段时间才能看到朝这个方向的明确倾斜。正如您所看到的，目前它并不是一个非常流行的 API 选择，而且开发人员在不久的将来是否会开始广泛使用它值得怀疑。

REST 受到普遍支持，并且已经在存在微服务的地方使用。除非您的用例需要gRPC实现，否则在这个初期阶段（在广泛采用之前）冒险采用它既不实际也没有必要。

目前以及在可预见的将来，REST API 都是最佳选择。

常见问题：gRPC 与 REST

问题 1：什么是 gRPC？它与 REST 有何不同？

gRPC是 Google 开发的高性能开源框架，旨在实现微服务之间的高效通信。它使用 HTTP/2 进行传输，使用 Protocol Buffer 进行序列化。REST（即表述性状态传输）是一种用于构建 Web 服务的流行架构风格，通常使用 HTTP/1.1 和 JSON 或 XML 进行数据交换。

Q2：gRPC 和 REST 之间的主要区别是什么？

• 协议：gRPC 依赖于 HTTP/2，提供更好的性能并减少延迟，而 REST 使用 HTTP/1.1。
• 数据格式：gRPC采用Protocol Buffers，一种二进制序列化格式，从而导致更小的有效负载和更快的通信；REST 通常利用 JSON 或 XML，它们是基于文本的格式。
• API设计：gRPC遵循RPC（Remote procedure Call）范式，让人感觉像调用本地函数；REST 遵循表述性状态转移模型的架构约束，重点关注资源和状态转换。
• Streaming：gRPC支持双向流式传输，实现客户端和服务器之间持续的数据交换；REST 仅限于请求-响应通信模式。

Q3：什么时候应该使用 gRPC 而不是 REST？

考虑在以下场景中使用 gRPC：

• 高性能通信和低延迟至关重要。
• 您需要支持客户端和服务器之间的实时流。
• 您更喜欢功能驱动的 API 设计。
• 您的系统严重依赖微服务。

Q4：gRPC 和 REST 可以在同一个项目中共存吗？

是的，gRPC 和 REST 可以在同一项目中共存。您可以实施混合方法，将 gRPC 用于特定的高性能微服务，将 REST 用于系统的其他部分。这使您能够利用这两种技术的优势来满足您的项目的要求。

Q5：gRPC 支持哪些语言和平台？

gRPC 支持多种编程语言，包括 C++、C#、Dart、Go、Java、Kotlin、Node.js、Objective-C、PHP、Python、Ruby 和 Swift。这种广泛的语言支持使其成为跨平台通信和多样化技术堆栈的理想选择。