REST、GraphQL 和 gRPC 之间的差异
原文链接(请科学上网):https://medium.com/javarevisited/difference-between-rest-graphql-and-grpc-10ac365462b8
朋友们大家好,如果大家正在通过学习 Spring Boot
和微服务知识来准备 Java
开发岗位的面试,我建议还应该准备一下 REST
、GraphQL
和 gRPC
等知识的内容,例如 REST
、GraphQL
和 gRPC
之间的差异,这也是 Java
面试中的热门问题之一。
在上一篇文章中,我分享了 JWT、OAuth 和 SAML 之间的差异;在本文中我将分享我对 REST
、GraphQL
和 gRPC
这三种流行的用于构建 Web
API
的通信协议的一些思考。
它们通常应用于通过网络进行相互通信的不同系统组件之间,例如使用 REST 可以在微服务之间进行同步通信。这些协议都有各自的优缺点,了解它们之间的差异不仅对于面试很重要,而且对于实际的项目中选择正确的协议也很重要。
在本文中,我们将学习 REST
、GraphQL
和 gRPC
之间的差异。我将解释每个协议背后的核心概念、它们的优缺点,并提供每种协议的一些实际使用场景。在本文结束时,我们应该能够更好地理解每种协议,最终能够满足我们的项目要求。
我们首先从一些简单的介绍开始,然后将会深入研究每一种协议,然后再总结它们之间的差异,以便大家清晰地了解它们的优缺点以及何时使用它们。
REST 即表述性状态转移,它是一种流行的协议,通常用于构建 Web
服务,这些服务通过 HTTP
公开数据和开放功能。它是基于 HTTP
的协议和一组约束,用来定义如何识别和定位某个资源以及如何对这些资源执行相关操作。
另一方面,GraphQL 是 Facebook
开发的 API
查询语言。它允许客户端准确指定它们所需要的数据,并且服务器仅响应指定的该数据内容。
GraphQL
的出现是为了解决 REST
的缺点和限制,因此它提供了一种更灵活、更高效的从服务器获取数据的方式,因为客户端可以在单个请求中请求多个资源。
gRPC 是一种用于创建 API
的高性能开源协议。它使用 Google
的 Protocol Buffers
作为数据格式,并提供对数据流和双向通信的支持。gRPC
因其性能和对多种编程语言的支持,经常用于微服务架构。
现在我们知道这些协议是什么了,接下来让我们深入研究它们。
顺便说一下,如果大家正在准备 Java
开发岗位的面试,还可以查看我之前发布的关于 21 个软件设计模式问题、10 个基于微服务场景的问题、20 个 SQL 查询面试题、50 个微服务问题、60 个关于树的数据结构问题、15 个系统设计问题、35 个 Java 核心问题 和 21 个 Lambda 和 Stream 问题 等文章,这些文章包含大量常见问题,可以帮助大家更好地准备面试。
什么是 REST?什么时候使用它?
正如我前面所说,REST
(表述性状态转移)是一种用于设计分布式应用程序的架构风格,尤其是基于 Web
的 API
的设计。 RESTful
API
使用 HTTP
方式(例如 GET
、POST
、PUT
、DELETE
)对 URL
(统一资源定位器)标识的资源执行 CRUD
(创建、读取、更新、删除)操作。
如果我们了解 HTTP
,那么我们就可以很容易了解 REST
。
REST
还依赖于无状态的客户端-服务器架构,其中来自客户端的每个请求都包含服务器完成请求所需要的所有信息,从而无需维护会话状态。
以下是一些不错的使用 REST
的场景:
- 当我们需要通过
API
公开数据和服务时,因为REST
是一种流行且完善的协议,用于创建可供其他应用程序和服务轻松使用的API
; - 当我们依赖于标准的
HTTP
方法和数据格式而需要支持多种平台和编程语言时,REST
可以被多种编程语言和平台使用; - 当我们需要缓存支持时,因为
REST
支持缓存,这可以提高性能并减少网络流量; - 当我们需要构建简单、轻量级的
API
时; - 当我们需要支持大量资源时。
此外,了解 HTTP
方法对于设计 REST
API
非常重要。
总体而言,REST
是一种灵活且被广泛采用的协议,对于许多类型的 API
来说都是不错的选择。但是它可能不是所有场景的最佳选择,尤其是那些需要实时更新或者是更复杂的查询和数据操作的场景,在这些情况下,其他协议(例如 GraphQL
或 gRPC
)可能更合适。
什么是 GraphQL?什么时候使用它?
GraphQL
是一种 API
查询语言,由 Facebook
于 2012
年开发,并于 2015
年作为开源项目发布。它被创建的初衷是为了解决 REST
的限制和缺点。
GraphQL
允许客户端定义他们需要的数据的结构,并且服务器可以准确地响应该数据,同时没有任何不必要的数据。它通常用作 RESTful
API
的替代方案,特别是在客户端需要对返回的数据进行细粒度控制的情况下。
以下是一些不错的使用 GraphQL
的场景:
- 当我们想要减少网络流量时,因为
GraphQL
允许客户端准确指定他们需要的数据,这可以减少通过网络传输的不必要的数据量; - 当我们需要支持各种客户端时,因为
GraphQL
支持强类型查询,这可用于确保客户端以它们可以理解的格式接收正确的数据; - 当我们需要支持实时更新时,因为
GraphQL
支持通过订阅进行实时更新,这允许客户端在更新可用时立即接收更新数据; - 当我们需要支持复杂的查询和数据操作时:因为
GraphQL
允许客户端使用简单的语法执行复杂的查询和数据操作操作,例如过滤、排序和聚合; - 当我们需要支持版本控制时,因为
GraphQL
允许客户端指定它们在请求中指定schema
的版本来支持版本控制,这可以让我们在schema
随着时间的推移而发生变化时更轻松地保持向后兼容性。
总的来说,GraphQL
是一个强大而灵活的协议,对于数据细粒度控制和实时更新很重要的场景来说,它是一个不错的选择。然而,它可能比 RESTful
API
需要更多的设置和配置,特别是当我们使用多种编程语言或平台时。
这里有一个很好的图表,突出显示了 REST
和 GraphQL
查询之间的区别:
什么是 gRPC?什么时候使用它?
现在让我们来学习什么是 gRPC
以及它能够提供什么? gRPC
是 Google
开发的一个高性能、开源的远程过程调用 (RPC
) 框架。它使用 Protocol Buffers
作为接口描述语言,支持多种编程语言,可以轻松构建跨不同平台和环境的分布式系统。
以下是一些不错的使用 gRPC
的场景:
- 当我们需要高性能和高效率时,因为
gRPC
使用二进制协议并支持流式传输,这可以使其比其他协议更快、更高效,特别是在高延迟或低带宽连接上; - 当我们需要支持多种编程语言时,因为
gRPC
支持多种编程语言,包括Java
、C
、Python
和Go
,可以轻松构建跨不同平台和环境的分布式系统; - 当我们需要支持实时更新时,因为
gRPC
支持双向流,这允许服务器实时向客户端发送更新; - 当我们需要处理大量数据时,因为
gRPC
使用Protocol Buffers
,它比JSON
或XML
等其他数据格式更高效、更紧凑,使其成为处理大量数据的不错选择; - 当我们需要构建微服务或分布式系统时,因为
gRPC
提供了强大而灵活的框架,用于构建可以水平扩展并处理大量流量的微服务和分布式系统。
总体而言,gRPC
是一个强大且高效的协议,对于性能、效率和实时更新很重要的场景来说,它是一个不错的选择。但是,与 RESTful
API
等其他协议相比,它可能需要更多的设置和配置,特别是当您使用多种编程语言或平台时。
这里有一个很好的图表,突出显示了 REST
、gRPC
和 GraphQL
协议之间的区别:
image_credit — https://medium.com/@LadyNoBug/grpc-v-s-rest-v-s-others-5d8b6eaa61df
REST、gRPC 和 GraphQL 之间的区别
现在我们已经了解什么是 REST
、gRPC
和 GraphQL
以及它们的工作原理,以下是 REST
、GraphQL
和 gRPC
之间的主要区别,请记住它们的主要特性以及何时在项目中使用它们:
REST:
- 表述性状态转移;
- 使用
HTTP
方法(GET
、POST
、PUT
、DELETE
)执行CRUD
操作; - 以结构化格式发送数据,通常是
JSON
或XML
格式; - 支持不同资源可以有多个端点;
- 客户端收到响应中的所有数据,即使它们并不需要全部数据;
- 支持缓存,但缓存管理可能很复杂;
- 完善且广泛采用,提供大量工具和文档。
GraphQL:
- 允许客户端准确指定它们需要什么数据,并且仅接收该数据;
- 使用单个端点访问多个资源;
- 拥有自己的查询语言,允许复杂的数据读取和其它操作;
- 可以支持通过订阅实时更新数据;
- 在某些情况下比
REST
更高效,特别是对于带宽有限的移动设备; - 与
REST
相比,缓存可以更细粒度且更易于管理; - 比
REST
需要更多的设置和配置,并且可能需要更多的专业知识才能高效地使用。
gRPC:
- 表示带有
Google
协议缓冲区的远程过程调用 (RPC
); - 使用二进制数据代替
HTTP
协议进行通信; - 支持流数据实时更新;
- 使用协议缓冲区进行序列化,这比
JSON
或XML
更高效; - 可以跨不同的编程语言使用;
- 专为微服务之间的高性能、低延迟通信而设计;
- 比
REST
需要更多的设置和配置,并且可能需要更多的专业知识才能高效地使用; - 可操作性可能不如
REST
或GraphQL
方便,因为它不是基于HTTP
这里总结了一个很好的表格,突出显示了 REST
、GraphQL
和 REST
之间的差异,我们可以使用它来复习前面的知识:
特性 | REST | GraphQL | gRPC |
---|---|---|---|
定义 | 表述性状态转移 | API 查询语言 | 使用 Protocol Buffers 的远程过程调用 |
支持的 HTTP 方法 | GET 、POST 、PUT 、DELETE | POST | 自定义方法 |
数据格式 | JSON 或者 XML | GraphQL 规范格式 | 二进制格式 |
endpoint 风格 | 支持多 endpoint | 单个 endpoint | 无 |
查询语言 | 无 | GraphQL | 无 |
实时更新 | 不支持(只能轮询) | 支持(通过订阅) | 支持(通过流机制) |
效率 | 中等 | 高 | 高 |
缓存能力 | 支持,但是管理比较复杂 | 支持细粒度缓存,管理比较方便 | 不常用,需要做很多设置 |
互操作性 | 高 | 中等 | 低 |
还值得注意的是,这些协议并不互斥,完全可以组合使用它们,充分利用它们之间的不同优势。
例如,我们可能对大多数 API
使用 REST
,但对某些资源密集型查询使用 GraphQL
,或者使用 gRPC
在微服务之间进行通信,同时对外部 API
客户端使用 REST
或 GraphQL
。
总结
这就是 REST
、GraphQL
和 gRPC
技术之间的差异。简而言之,REST
是一种用于创建 Web
服务的流行协议,受到 HTTP
的启发并充分利用 HTTP
提供的能力;而 GraphQL
是一种查询语言,允许客户端准确指定他们需要从服务器获取哪些数据,它的出现是为了解决 REST
协议的缺点,因此如果我们正在努力维护 REST
API
,那么它绝对是一个可行的选择。
另一方面,gRPC
是一个高性能、开源的协议,常用于微服务架构中。
这些协议中的每一种都有不同的用途,并且它们都可以一起使用,为 Web
应用程序提供全面且高效的通信系统。
这是我认为每个 Java
开发人员都应该准备的面试问题,但如果大家想要了解更多,还可以准备微服务面试问题,例如API Gateway 和 Load Balancer 的区别、SAGA 模式、如何在微服务中管理事务 以及 SAGA 和 CQRS 模式的区别,它们在面试中很受欢迎。