REST、GraphQL 和 gRPC 是现代 Web 应用程序中最流行的 3 种 API 开发技术。那么在做技术选型时，三者要如何选择呢？
在本文中，我们将一起对比 REST、GraphQL 和 gRPC 的特性和用法。
REST——最流行的技术
REST
Representational State Transfer (REST) 是现代 Web 开发中最流行的 API 开发技术。它是一个无状态的数据传输架构。客户端请求时会包含该请求所需的所有详细信息，但是服务器不保留客户端的状态。
REST API 支持 HTTP 原生缓存 header 并使用 HTTP 方法（POST、GET、PUT、PATCH 和 DELETE）来操作数据。因为 REST 的学习门槛较低，所以大家都能轻松使用 REST。
REST 易于扩展且可靠，如果我们还在犹豫不决时，可以优先选择它。
REST的好处
- 可以放心地使用标准 HTTP 方法实现 CRUD 操作。
- REST 已经很成熟，有完善的文档，上手简单。
- 支持缓存。
- 友好的可扩展性，并提供客户端和服务器之间的分离。
- 可以轻松地将其集成到应用程序中。
REST的缺点
- 存在过度获取和获取不足的问题。当API返回比实际需要的数据更多时，就会发生过度获取。这可能会导致不必要的网络流量、较慢的性能和额外的带宽使用。获取不足发生在API没有返回特定用例所需的所有必要数据时，需要多个请求才能检索所有所需信息。这也可能导致较慢的性能和增加的网络流量，以及更复杂的代码库。
- 不能维持状态。
- 相对来说比较大的 payload。
- 随着应用程序的扩展，端点的数量急剧增加。
- 不容易更新数据库模式或数据结构。
何时选择 REST
如果没有特定要求，REST 是最佳选择。如果是开发新手，那么使用 REST 是完美的选择，因为它的学习曲线较浅。此外，它还拥有庞大的生态系统，你可以轻松找到问题的解决方案。
在处理较大的请求量和带宽有限时最好使用 REST，因为可以使用它的缓存支持来提高性能。
总的来说，如果你的应用程序没有明确需要使用 GraphQL 或 gRPC，那么就可以使用 REST。
GraphQL——客户端驱动的标准
GraphQL 是 2015 年推出的一种数据查询语言，支持开发人员精确定位和获取他们需要的数据。与 REST 相比，GraphQL 是一种客户端驱动的方法，客户端可以决定需要什么数据、如何获取数据和格式。它还解决了过度获取和获取不足的问题，因为客户端可以明确指定所需的数据。
GraphQL 使用查询、变更和订阅来操作数据。
- 查询：从服务器请求数据。
- 变更：修改服务器端数据。
- 订阅：在数据更新时，通过订阅获得实时更新的数据。
GitHub 是使用 GraphQL 的最大公司之一。它在 2016 年从 REST 转向 GraphQL，极大地帮助了 GitHub 的快速增长。
GraphQL 的好处
- 非常灵活，可以准确地满足客户的需求。
- 没有过度获取和获取不足的问题。
- 主流语言支持，包括 JavaScript、Java、Python、Ruby 和 PHP。
- 允许自定义数据的结构。
- 单个查询可以包含来自多个资源的字段。
GraphQL 的缺点
- 查询可能很复杂。
- 缺乏内置的缓存支持。
- 与 REST 相比，学习 GraphQL 更具挑战性。
- 默认不支持文件上传。
何时选择 GraphQL
当查询包含数据库的许多记录时，GraphQL 是最佳选择。你可以使用 GraphQL 消除过度获取，并仅查询必要数据以提高应用程序性能。此外，GraphQL 非常适合需要从多个资源聚合数据的情况。
当你还不完全了解客户端使用 API 的原理时，也可以使用 GraphQL。使用 GraphQL 时，你无需预先定义严格的协议，可以根据客户反馈逐步构建 API。
gRPC——一种以性能为导向的技术
gRPC 是 Google 于 2016 年推出的远程过程调用的进化版本。它是一种轻量级解决方案，使用最少的资源提供最大的性能。
gRPC 遵循基于协议的通信方法。它要求客户端和服务器在开始通信之前都有协议。gRPC 使用 Protobuf（一种声明性语言）创建协议，并使用选定的语言为客户端和服务器生成兼容的代码。
gRPC支持的通信方式有4种：
- Unary ：客户端发送一个请求并等待单个响应。
- Server streaming ：客户端发送一个请求并接收多个响应。
- Client streaming ：客户端发送多个请求并等待单个响应。
- Bidirectional streaming ：客户端发送多个请求并接收多个响应。
gRPC 的好处
- 开源。开发人员可以根据需要对其进行修改。
- 支持多种语言，包括 JavaScript、Java、C、C++、C#、Kotlin、Python、Go 和 PHP。
- 能够进行负载均衡。
- 与 REST API 相比，它默认使用 HTTP2 来减少延迟。
- 使用二进制格式序列化数据。
- 支持全双工流媒体。
gRPC 的缺点
- 学习曲线较陡峭：与传统的REST API相比，gRPC需要掌握新的概念和技术，例如Protocol Buffers和流。
- 可读性差：由于使用二进制编码，gRPC的消息不像JSON或XML那样易于人类阅读和理解。
- 难以调试：由于消息是二进制编码的，调试gRPC服务可能比调试REST API更加困难。
- 不适合小型应用：对于只有少量服务和少量数据的小型应用程序来说，gRPC可能过于复杂，增加了不必要的开销。
- 不支持Web浏览器：由于gRPC使用HTTP/2协议，而Web浏览器目前还不支持HTTP/2协议的所有功能，因此不能在Web浏览器中使用gRPC。
何时选择 gRPC
- 需要高效的数据传输：由于gRPC使用二进制协议，因此比JSON和XML等文本协议更快、更轻量级。
- 需要高可靠性：gRPC的基于HTTP/2协议的传输层提供了许多功能，例如流控制、连接复用和头部压缩等，这些功能可以提高可靠性和性能。
- 需要高效的多语言通信：gRPC支持多种编程语言，并提供了自动生成代码的工具，因此不需要手动编写跨语言的代码。
- 需要支持多种请求和响应类型：gRPC支持四种类型的通信方式（Unary、Server streaming、Client streaming和Bidirectional streaming），因此可以选择最适合特定用例的通信方式。
- 需要更好的API管理：gRPC提供了强大的API管理工具，例如gRPC-Gateway和Envoy等，这些工具可以提高API的可发现性、文档化和测试。
gRPC 可以用在微服务架构中来处理服务之间的通信，因为它可以与用不同语言编写的服务进行通信。
结论
选择REST、GraphQL和gRPC取决于你的具体场景和需求，基本原则总结如下：
- REST：REST适合简单的API和Web服务，例如传统的CRUD操作。它通常更易于理解和使用，并且具有广泛的支持和工具生态系统。
- GraphQL：GraphQL适合需要灵活性和高级查询功能的应用程序。如果你的应用程序需要从多个资源聚合数据，或者需要更好地控制数据的格式和粒度，则GraphQL是一个不错的选择。
- gRPC：gRPC适合需要高效和可靠数据传输的应用程序。如果你需要在多种编程语言之间进行高效通信，并且希望提供更高的性能和可靠性，则gRPC是一个不错的选择。
不过，REST、GraphQL和gRPC并不是相互排斥的选择。在实际情况下，你可以结合使用，以满足具体需求和场景。
