昆山汽车网站建设,wordpress关键词调用,男直接做的视频网站,济南微信网站本文对gRPC和REST的特征和区别进行了介绍#xff0c;这可能是当今创建API最常用的两种方法。 文章目录
一、gRPC的介绍
二、什么是REST#xff1f;
三、什么是gRPC?
四、gRPC和REST的比较
#xff08;1#xff09;底层HTTP协议
#xff08;2#xff09;支持的数据…本文对gRPC和REST的特征和区别进行了介绍这可能是当今创建API最常用的两种方法。 文章目录
一、gRPC的介绍
二、什么是REST
三、什么是gRPC?
四、gRPC和REST的比较
1底层HTTP协议
2支持的数据格式
3数据大小
4吞吐量
5定义
6易于采用
7工具支持
总结 以下将从这两种工具的特征开始也就是它们是什么以及提供什么功能。然后将根据七个方面对它们进行比较这对现代系统来说是最重要的7个类别。
其类别如下
底层HTTP协议支持的数据格式数据大小吞吐量定义易于采用工具支持
一、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请求方法来管理其资源。
示例用DELETE user/1代替GET user/deleteById/1
至于HTTP方法及其相关操作如下所示
GET—检索特定的资源或资源集合。POST—创建一个新的资源。PUT—修改整个资源。PATCH -特定资源的部分更新。DELETE—删除指定id的资源。
成熟度模型规定的远不止这些。例如称为HyperMedi的概念。HyperMedia将数据的呈现和对客户端可以执行的操作的控制结合在一起。
对成熟度模型的完整描述超出了本文的范围。
三、什么是gRPC?
gRPC是远程过程调用RPC这个相对古老的概念的另一种实现。谷歌的开发人员创建了它这就是为什么它的名称里有“g”的原因。它可能是处理RPC最现代和最有效的工具也是CNCF孵化项目。
gRRC使用谷歌公司的协议缓冲区作为序列化格式同时利用HTTP/2作为传输介质数据尽管gRPC也可以使用JSON作为数据层。
方法gRPC的基本构建块每个方法都是一个远程过程调用它接受一些输入并返回输出。它执行用所选编程语言进一步实现的单个操作。目前gRPC支持4种方法 ① 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连接发送多个请求-响应对。这种方法可以显著地提高应用程序的性能。
结果gRPC略有获胜
2支持的数据格式
假设REST API使用HTTP/1.1的默认情况那么它可以支持多种格式。
REST通常不对消息格式和样式施加任何限制。基本上任何一种可以序列化为普通旧文本的格式都是有效的。用户可以在特定场景中使用最适合自己的任何格式。
在REST应用程序中发送数据的最流行格式无疑是JSON。XML排在第二位因为有大量的较旧/遗留应用程序。
然而当使用REST和HTTP/2时只支持二进制交换格式。在这种情况下可以使用Protobuf或Avro。当然这种方法也有它的缺点但在以下几点中会详细说明这一点。
同时gRPC只支持两种数据交换格式 ①Protobuf —默认情况下。 ②JSON—当需要与原有API集成时。 如果用户尝试使用JSON那么gRPC将使用JSON作为消息的编码格式而使用GSON作为消息格式。此外使用JSON需要做更多的配置。
结果REST获胜因为它支持更多格式。
3数据大小
默认情况下gRPC使用二进制数据交换格式这显著地减少了通过网络发送的消息的大小研究表明以字节计算大约减少了40%50%而从以前的一个项目中获得的经验表明甚至减少了50%70%。
以上提供了JSON和Protobuff之间相对深入的大小比较。本文作者还提供了一个生成JSON和二进制文件的工具。这样就可以重新运行他的实验并比较结果。
本文中的对象相当简单。不过一般的规则是——嵌入的对象越多JSON的结构越复杂它就会比Protobuf更重。50%的大小差异有利于Protobuf 是一个很好的基线。
在使用REST的二进制交换格式时可以最大限度地减少或消除这种差异。然而这不是最常见的也不是最受支持的RESTful API方式因此可能会出现其他问题。
结果默认情况下gRPC获胜在两者都使用二进制数据格式的情况下双方为平局。
4吞吐量
同样在REST的情况下一切都取决于底层HTTP协议和服务器。
在默认情况下基于HTTP/1.1的REST即使是最高性能的服务器也无法击败gRPC的性能特别是当使用JSON时添加序列化和反序列化开销时。虽然当切换到HTTP/2时差异似乎有所减少。
至于最大吞吐量在这两种情况下HTTP都是一种传输媒介因此它具有无限扩展的潜力。因此一切都取决于正在使用的工具以及对应用程序的精确操作因为设计没有限制。
结果默认情况下为gRPC在同时使用二进制数据和HTTP/2的情况下gRPC略胜一筹。
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特别是尽管在这一点上有点过时但仍然被视为一种新奇事物。
结果REST被更广泛地采用并且有更多的库和框架。
7工具支持
以上已经介绍了库、框架和一般市场份额所以在这一部分中介绍围绕这两种风格的工具。它意味着用于测试、性能/压力测试和文档的工具。
①自动化测试
首先在REST的情况下用于构建自动化测试的工具被构建到不同的库和框架中或者是为了这个唯一目的而构建的独立工具比如REST-assured。
在gRPC的情况下可以生成一个stub并将其用于测试。如果想要更严格可以将生成的客户端作为一个单独的应用程序使用并将其用作对实际服务进行测试的基础。
关于gRPC的外部工具支持需要知道
Postman程序对gRPC的支持。在IDE中使用的JetBrains HTTP客户端也可以通过一些最低配置来支持gRPC。结果一REST获得胜利。然而gRPC的情况似乎有所改善。
②性能测试
在这里REST具有显著的优势因为像JMeter或Gatling这样的工具使REST API的压力测试变得相当容易。
不幸的是gRPC没有这样的支持。在当前的Gatling版本中包含了gRPC插件所以情况似乎正在好转。
然而到目前为止只有一个名为ghz的非官方插件和库。这些都很好它只是与REST的支持级别不同。
结果二REST的胜利然而gRPC的情况似乎有所改善。
③文档
在API文档方面随着OpenAPI和Swagger在整个行业被广泛采用并成为事实上的标准REST再次取得了胜利。几乎所有用于REST的库都能够以最小的努力或开箱即用的方式公开Swagger文档。
不幸的是gRPC没有这样的文档。
然而问题是gRPC是否需要这样的工具。gRPC在设计上比REST更具描述性因此可能需要其他文档工具。
一般来说带有API描述的.proto文件比负责编写REST API代码的代码更具声明性和紧凑性因此可能不需要gRPC提供更多文档。
结果三REST的胜利。然而关于gRPC文档的问题是开放的。
④总体结果
这是REST的一次重大胜利。
总结
以下是gRPC和REST比较的最终得分表。 得出的结论是gRPC和REST的比较结果平分秋色各有三场胜利没有明显的赢家。
因此没有什么灵丹妙药用户只需要考虑哪些类别可能对应用程序最重要然后选择在大多数类别中获胜的方法。
本文作者表示如果可以的话他会尝试使用gRPC因为gRPC在他的上一个项目中运行得非常好。它可能是比原有的REST更好的选择。
善用工具
成功的前端工程师很会善用工具这些年低代码概念开始流行像国外的 Mendix国内的 JNPF这种新型的开发方式图形化的拖拉拽配置界面并兼容了自定义的组件、代码扩展确实在 B 端后台管理类网站建设中很大程度上的提升了效率。
开源地址JNPF体验中心
代码量少系统的稳定性和易调整性都会得到一定的保障。基于代码生成器可一站式开发多端使用 Web、Android、IOS、微信小程序。代码自动生成后可以下载本地进行二次开发有效提高整体开发效率。同时支持多种云环境部署、本地部署给予最大的安全保障可以快速搭建适合自身应用场景的产品。
原文标题gRPC vs RESTComparing Approaches for Making APIs
