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/ target=_blank class=infotextkey>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并不是相互排斥的选择。在实际情况下,你可以结合使用,以满足具体需求和场景。
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,不构成投资建议。投资者据此操作,风险自担。如有任何标注错误或版权侵犯请与我们联系,我们将及时更正、删除。