文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

gRPC vs REST:创建API的方法比较

2024-11-30 09:52

关注

审校 | 重楼

本文对gRPC和REST的特征和区别进行介绍,这可能是当今创建API最常用的两种方法。

以下将从这两种工具的特征开始,也就是它们是什么以及提供什么功能。然后,将根据七个方面对它们进行比较,这对现代系统来说是最重要的7个类别。

其类别如下:

(1)底层HTTP协议

(2)支持的数据格式

(3)数据大小

(4)吞吐量

(5)定义

(6)易于采用

(7)工具支持

gRPC的介绍

当人们听到API时,可能马上想到REST API。然而,REST是构建API的众多方法之一。它并不是适用于所有用例的灵丹妙药。还有其他方法,远程过程调用 (RPC)只是其中之一,而gRPC可能是使用RPC最成功的框架。

尽管gRPC是一种相当成熟和高效的技术,但它仍然被视为一种新技术。因此,尽管在某些用例中非常方便,但它没有REST被广泛采用。

本文主要介绍gRPC,并指出它可以发挥作用的用例。

什么是REST

表述性状态转移(REST)可能是创建公开任何类型API的应用程序的最常用方法。它使用HTTP作为底层通信媒介。正因为如此,它可以从HTTP的所有优点中获益,例如缓存。

REST的两个关键概念是:

(1)端点:表示特定资源的唯一统一资源定位符(URL);可以看作是通过互联网访问特定操作或数据元素的一种方式。

(2)资源:在特定URL下可用的特定数据块。

此外,还有一个叫做Richardson成熟模型的描述——这是一个描述REST API中“专业性”程度的模型。它根据特定API具有的特征集将REST API划分为3个级别(或4个级别,取决于是否将级别0计算在内)。

其中一个特征是REST端点应该在URL中使用名词,并使用正确的HTTP请求方法来管理其资源。

至于HTTP方法及其相关操作,如下所示:

成熟度模型规定的远不止这些。例如称为HyperMedi的概念。HyperMedia将数据的呈现和对客户端可以执行的操作的控制结合在一起。

对成熟度模型的完整描述超出了本文的范围。

什么是gRPC?

gRPC是远程过程调用(RPC)这个相对古老的概念的另一种实现。谷歌的开发人员创建了它,这就是为什么它的名称里有“g”的原因。它可能是处理RPC最现代和最有效的工具,也是CNCF孵化项目。

gRRC使用谷歌公司的协议缓冲区作为序列化格式,同时利用HTTP/2作为传输介质数据,尽管gRPC也可以使用JSON作为数据层。

Unary:经典的请求-响应模型,方法接受输入并返回输出。

②服务器流:方法接受消息作为输入,同时返回消息流作为输出。gRPC保证了单个RPC调用中的消息排序。

③客户端流:该方法将消息流作为输入,处理它们直到没有消息为止,然后返回一条消息作为输出。与上面类似,gRPC保证在单个RPC调用中进行消息排序。

④双向流:该方法将消息流作为输入,并将消息流作为输出返回,有效地使用了读和写两个消息流。两个流都独立运行,并且消息顺序保留在流级别上。

gRPC API定义以.proto文件的形式编写,其中包含上述所有三个基本构建块。此外,gRPC提供了一个协议缓冲区编译器,它从.proto文件生成客户端和服务代码。

用户可以随心所欲地实现服务器端方法,必须坚持使用API的输入输出契约。

在客户端,有一个叫做客户端(或stub)的对象——类似于HTTP客户端。它知道来自服务器的所有方法,只处理调用远程过程并返回它们的响应。

gRPC和REST的比较

(1)底层HTTP协议

这是第一类,可能也是最重要的一类,因为它的影响也可以在其他方面看到。

一般来说,REST是基于请求-响应的,并使用HTTP/1.1作为传输媒介。这里必须使用不同的协议,例如WebSocket或任何类型的流或更持久的连接。

还可以实现一些简单的代码,使REST看起来像消息流。更重要的是,使用HTTP/1.1 REST需要每个请求-响应交换一个连接。对于长时间运行的请求,或者当网络容量有限时,这种方法可能会有问题。

当然,可以使用HTTP/2来构建类似REST的API;然而,并不是所有的服务器和库都支持HTTP/2。因此,其他地方可能会出现问题。

另一方面,gRPC只使用HTTP/2。它允许通过单个TCP连接发送多个请求-响应对。这种方法可以显著地提高应用程序的性能。

(2)支持的数据格式

假设REST API使用HTTP/1.1的默认情况,那么它可以支持多种格式。

REST通常不对消息格式和样式施加任何限制。基本上,任何一种可以序列化为普通旧文本的格式都是有效的。用户可以在特定场景中使用最适合自己的任何格式。

在REST应用程序中发送数据的最流行格式无疑是JSON。XML排在第二位,因为有大量的较旧/遗留应用程序。

然而,当使用REST和HTTP/2时,只支持二进制交换格式。在这种情况下,可以使用Protobuf或Avro。当然,这种方法也有它的缺点,但在以下几点中会详细说明这一点。

同时,gRPC只支持两种数据交换格式:

Protobuf 默认情况下。

JSON—当需要与原有API集成时。

如果用户尝试使用JSON,那么gRPC将使用JSON作为消息的编码格式,而使用GSON作为消息格式。此外,使用JSON需要做更多的配置。

(3)数据大小

默认情况下,gRPC使用二进制数据交换格式,这显著地减少了通过网络发送的消息的大小:研究表明,以字节计算,大约减少了40%~50%,而从以前的一个项目中获得的经验表明,甚至减少了50%~70%。

以上提供了JSON和Protobuff之间相对深入的大小比较。本文作者还提供了一个生成JSON和二进制文件的工具。这样就可以重新运行他的实验并比较结果。

本文中的对象相当简单。不过,一般的规则是——嵌入的对象越多,JSON的结构越复杂,它就会比Protobuf更重。50%的大小差异有利于Protobuf 是一个很好的基线。

在使用REST的二进制交换格式时,可以最大限度地减少或消除这种差异。然而,这不是最常见的,也不是最受支持的RESTful API方式,因此可能会出现其他问题。

(4)吞吐量

同样,在REST的情况下,一切都取决于底层HTTP协议和服务器。

在默认情况下,基于HTTP/1.1的REST,即使是最高性能的服务器也无法击败gRPC的性能,特别是当使用JSON时添加序列化和反序列化开销时。虽然当切换到HTTP/2时,差异似乎有所减少。

至于最大吞吐量,在这两种情况下,HTTP都是一种传输媒介,因此它具有无限扩展的潜力。因此,一切都取决于正在使用的工具以及对应用程序的精确操作,因为设计没有限制。

(5)定义

在这一部分中,将描述如何在这两种方法中定义消息和服务。

在大多数REST应用程序中,只是将请求和响应声明为类、对象或特定语言支持的任何结构。然后,依靠提供的库来序列化和反序列化JSON/XML/YAML或任何需要的格式。

此外,目前正在努力创建能够根据Swagger的REST API定义用所选编程语言生成代码的工具。然而,它们似乎是在alpha版本中,所以仍然可能会出现一些错误和小问题,这将使它们难以使用。

REST应用程序的二进制格式和非二进制格式之间几乎没有区别,因为这两种情况下的规则大致相同。对于二进制格式,只是以特定格式所需的方式定义所有内容。

此外,可以通过来自底层库或框架的方法或注释来定义REST服务。该工具还负责将其与其他配置一起向外部世界公开。

在gRPC的情况下,将Protobuf作为默认的并且事实上是编写定义的唯一方式。必须在.proto文件中声明所有内容消息、服务和方法,所以事情非常简单。

然后使用gRPC提供的工具生成代码,只需要实现自己的方法。在那之后,一切都应该按预期工作。

此外,Protobuf支持导入,因此能够以一种相当简单的方式将设置扩展到多个文件。

(6)易于采用

在这一部分中,将比较现代编程语言中对每种方法的库/框架支持。

本文作者表示,在他作为软件工程师的职业生涯中,遇到的每种编程语言(Java、Scala、Python)都至少有3个主要的库/框架用于创建类REST应用程序,更不用说将JSON解析为对象/类的库了。

此外,由于REST默认使用人类可读的格式,因此对于新手来说,它更容易调试和使用。这也会影响交付新特性的速度,并帮助用户应对代码中出现的错误。

长话短说,对REST风格应用程序的支持至少非常好。

在Scala中,甚至有一个叫做Tapir的工具。Tapir允许用户抽象HTTP服务器,并编写可用于多个服务器的端点。

gRPC本身为超过8种流行的编程语言提供了客户端库。这通常就足够了,因为这些库包含了制作gRPC API所需的所有内容。此外,一些库为Java(通过Spring Boot Starter)和Scala提供了更高的抽象。

另一件事是,REST如今被认为是一个世界性的标准和构建服务的切入点,而RPC和gRPC,特别是,尽管在这一点上有点过时,但仍然被视为一种新奇事物。

(7)工具支持

以上已经介绍了库、框架和一般市场份额,所以在这一部分中介绍围绕这两种风格的工具。它意味着用于测试、性能/压力测试和文档的工具。

自动化测试

首先,在REST的情况下,用于构建自动化测试的工具被构建到不同的库和框架中,或者是为了这个唯一目的而构建的独立工具,比如REST-assured。

在gRPC的情况下,可以生成一个stub并将其用于测试。如果想要更严格,可以将生成的客户端作为一个单独的应用程序使用,并将其用作对实际服务进行测试的基础。

关于gRPC的外部工具支持,需要知道:

性能测试

在这里,REST具有显著的优势,因为像JMeter或Gatling这样的工具使REST API的压力测试变得相当容易。

不幸的是,gRPC没有这样的支持。在当前的Gatling版本中包含了gRPC插件,所以情况似乎正在好转。

然而到目前为止,只有一个名为ghz的非官方插件和库。这些都很好;它只是与REST的支持级别不同。

文档

在API文档方面,随着OpenAPI和Swagger在整个行业被广泛采用并成为事实上的标准,REST再次取得了胜利。几乎所有用于REST的库都能够以最小的努力或开箱即用的方式公开Swagger文档。

不幸的是,gRPC没有这样的文档。

然而,问题是gRPC是否需要这样的工具。gRPC在设计上比REST更具描述性,因此可能需要其他文档工具。

一般来说,带有API描述的.proto文件比负责编写REST API代码的代码更具声明性和紧凑性,因此可能不需要gRPC提供更多文档。

总体结果

这是REST的一次重大胜利。

总结

以下是gRPC和REST比较的最终得分表。

得出的结论是:gRPC和REST的比较结果平分秋色,各有三场胜利,没有明显的赢家。

因此没有什么灵丹妙药,用户只需要考虑哪些类别可能对应用程序最重要,然后选择在大多数类别中获胜的方法。

本文作者表示,如果可以的话,他会尝试使用gRPC,因为gRPC在他的上一个项目中运行得非常好。它可能是比原有的REST更好的选择。

原文gRPC vs REST:Comparing Approaches for Making APIs,作者:Bartłomiej Żyliński

来源:51CTO内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯