说到软件开发，你可能听说过REST 这样的词。REST 是一个非常常用的API架构，开发者广泛使用它来设计软件API。应用编程接口对任何软件应用都是至关重要的，而REST 是用于API的众多架构之一。
如今。 gRPC架构越来越受欢迎，它也声称可以解决一些传统上与REST API相关的问题。但它们的区别在哪里？以及你应该为你的应用程序使用哪一个？为了知道这些问题的答案，我们需要更多地了解 gRPC与REST ，以及它们在哪些情况下表现更好。但在我们进入这一切之前，让我们看看什么是API，以及它们为微服务带来了什么。
什么是API？
软件应用可以通过使用应用编程接口--API来进行互动和交流，API作为技术中介来运作。一个API负责将用户的请求发送给系统，然后从系统中接收回复。
想象一下，你在网上订购一部手机。你去了一个与网络相连的网站，它将你的查询信息发送到一个服务器。然后服务器得到信息，对其进行分析，并在采取必要的步骤后，将显示在我们屏幕上的细节回复给我们。这在API中成为可能。
API概述了如何执行这种客户端请求，使用什么数据结构，以及客户端必须遵守的标准。它还描述了一个程序可以向另一个程序发送的查询种类。这两种 gRPCvsREST 架构风格被广泛用于设计API。
APIs和微服务
应用程序可以有一个单体架构，也可以有一个微服务架构。在单体应用中，软件的所有功能和模块都包含在一个单一的单元或代码库中。相比之下，微服务应用程序则由许多较小的单元组成，它们通过HTTP协议等接口相互作用。
单片式的主要问题是，随着工程师在原有的基础上附加新的功能和服务，改变、更新和扩展系统变得更加困难。对应用程序的一个方面的改变可能会对其他部分产生不利的影响。单片机的代码在经过无数次的扩展、更新和改变后，逐渐变得盘根错节，难以理解，以至于需要进行完整的系统重新设计。
这个问题通过微服务得到了解决。这种架构设计将一个单体划分为其组成部件，然后将每个部件作为一个单独的应用程序运行。这些应用程序中的每一个都被称为一个微服务。然后，这些不同的微服务使用API进行连接。这个由API连接的微服务集合在一起，构建了一个更大的架构设计。API使纳入微服务架构的每个组件之间的连接和通信成为可能。一些创建API的流行方法是：GraphQL 。 RPC，以及REST 。
什么是 RPC?
一个 RPC- 远程过程调用 - 是一种网络架构，它使你能够使用预定义的表格在远程服务器上执行一项服务，并获得相同格式的响应。执行查询的服务器的风格，无论是本地服务器还是远程服务器，在设计上都没有考虑。 RPC设计。
图片来源itrelease.com/作者Junaid Rehman
一个API请求的基本功能 RPCAPI请求的基本功能与REST API的功能相同。API请求 RPCAPI请求指定了交互的准则和使交互成为可能的技术。后来，用户使用参数调用这些功能。URL的请求字符串包含用于调用操作的参数。
为了创建API请求，该 RPC 系统使用一个客户-服务器结构。 RPC解释用户请求的信息并将其传送到服务器。虽然服务器内的内部通信是隐蔽的，但服务器会对用户作出回应。该 RPC模式也使用户能够以特定的方式要求服务。 RPC具有在分散和内部场景中支持远程过程调用的优势。
什么是REST ？
REST - Representational State Transfer - 指的是一种客户-服务器架构，用户可以通过JSON 或XML通信访问后台信息。一个API被认为是RESTful的，如果。
- 它有一个一致的接口，并向API客户提供特定的应用资源。
- 服务器和客户端分开独立工作。只有指向应用程序组件的URI会被客户端知道。
- 它是无状态的。这意味着只有客户端会保存任何状态信息。服务器不会保存关于客户端查询的任何状态数据。
- 由API提供的应用程序资产必须是可缓存的。
- 它有一个分层的架构。
它是当代架构设计的一个应用，它依赖于几个限制，允许超媒体网络中的数据传输。一个RESTful网络API需要URL编码的参数来连接到使用HTTP协议的服务。 REST API在当代网络设计中被广泛接受，以创建无状态、可扩展和可靠的API。
当REST API被公开访问时，每个结合微服务系统的组件都可以作为资产显示给用户或客户。这个资源可以使用HTTPGET,POST,PUT 和DELETE 命令进行查询。
REST 是如何工作的？
REST 在与API请求中指定的服务合作时，使用HTTP协议作为默认的通信协议。资源是一种东西，相当于面向对象设计中的对象。RESTful资源有动作和属性，很像一个对象。一般来说， 实现通常不太考虑RESTful动作，而更多地集中在资源的属性上。RESTful解决方案是那些仅仅使用属性来表示RESTful资源的解决方案。REST
在RESTful API中，用户向一个URL--统一资源定位器--提交查询，这会导致一个带有有效载荷的回复，其格式为JSON 、XML或任何支持的数据格式。这个有效载荷代表了用户想要的资源。常见的客户端请求包括
- 一个HTTP方法，指定在资源上要处理的内容
- 资源的路径
- 有关于查询的数据的标头
- 客户端特定的信息有效载荷
在头的接受字段中，用户指定他们能够接受的数据类型。API服务器在向查询的用户提供数据有效载荷时，会发送一个内容类型头，以确定响应体中采用的消息传递格式。响应体中还包括一个告知用户API调用结果状态的回复代码。
什么是 gRPC?
gRPC- 谷歌远程过程调用 - 是RPC 设计的一个子类型。 gRPC是一种高性能的全球开源的RPC 架构，保证了微服务架构的灵活性和速度。函数调用是由 gRPC来确保使用各种编码语言创建的微服务中的客户互动。
这种技术使用HTTP 2.0标准实现了RPC API请求，但服务器和API程序员都不知道HTTP。因此，复杂性减少了，因为没有理由担心RPC 原则如何被转化为HTTP。
谷歌远程过程调用寻求加快微服务间的数据传输。为了允许远程返回和调用，它是基于一种策略，即识别服务，建立方法论，并指定相关的变量。
此外，它使用IDL --接口描述语言--来指定RPC API范式，使得识别远程功能更加简单。IDL 默认采用协议缓冲器来定义服务接口和有效载荷消息的格式。
如何 gRPC如何工作？
HTTP/2协议、流媒体和协议缓冲区或protobufs ，由 gRPCAPIs来传输消息。一种称为protobuf的序列化标准允许自动创建用户库和直接构建微服务。在proto文件中，API设计者描述了跨服务器和客户端发送的操作和消息。
protoc 编译器加载文件并创建用户和服务器软件，用于与远程服务进行通信。与XML或JSON 格式相比，用协议缓冲区加密的消息要小得多，使处理过程不那么CPU-密集。
此外，使用HTTP/2。 gRPCAPI为RPC 设计带来了各种改进。该协议增加了一个二进制格式层，将数据包分割成更小的、二进制框架的消息，使其可运输且体积小。由于HTTP/2支持双向通信架构的多个同时查询，使得在一个通道内执行许多调用成为可能。
HTTP/2传输协议支持多个并发的流，但是 gRPCAPI通过通道来扩展这一功能。每个通道都可以通过许多并发连接容纳多个流同时运行。通道提供了一种直接的方法来连接到给定地址和端口的API服务器。客户端存根也可以通过通道来实现。
gRPCvsREST: 比较
谷歌创建了 gRPC作为一个RPC 的变体来处理现有API架构风格的一些限制。它解决了与REST API相关的一些问题，但 gRPC由于它是一种较新的技术，API面临某些问题。有许多用例，REST API可能更适合你的应用。一旦你知道这两者之间的区别，你就可以决定哪种API可能更适合你的软件。
HTTP 1.1与HTTP 2
REST APIs所使用的请求-回复方法主要是基于HTTP 1.1。这意味着，如果一个微服务从多个客户端获得许多查询，该模型必须单独处理每个查询，这将拖累整个系统的运行。 REST API可以在HTTP 2上开发，但由于通信架构仍然是请求-响应，它们无法充分利用HTTP 2的优势，包括双向兼容和流式互动。
gRPCAPI不会遇到这种挑战。它坚持客户-响应的连接模式，并基于HTTP 2。 gRPC可以接受来自不同客户的许多查询，并通过流式信息同时处理这些请求。这些情况允许双向通信与流式互动。此外。 gRPC支持像HTTP 1.1所创造的那些单项互动。
gRPC APIs可以管理。
- 单一的相互作用
如果一个客户提出一个请求，但只得到一个回复，作为回报。 - 服务器流
只要服务器以信息流的方式回答客户的查询，就被称为服务器流。服务器在提供所有数据后还会发送一个状态消息来结束这个过程。 - 客户端流
这发生在客户端提供一连串的消息，而服务器用一条消息来回应的时候。 - 双向流
这允许以两种方式传输数据，因为服务器和客户端通道是相互独立的。
浏览器支持
由于大多数网络API交互都是在网上进行的，所以浏览器的支持是一个关键的考虑因素。 gRPC与REST 。浏览器支持可能是REST APIs相对于 的关键优势之一。 gRPC.所有的浏览器都提供完整的REST API能力和浏览器支持。浏览器的功能 gRPC然而，在浏览器中，.NET的功能仍然是相对有限的。不幸的是，跨越HTTP 1.1和HTTP 2的转换需要gRPC-web以及代理层。结果是。 gRPCAPI往往最终主要用于内部或私人系统，例如，用于特定组织的后台信息和功能的API应用。
多重流与HTTP/2协议一起使用。因此，众多客户可以并行发送查询，而不需要为每个客户打开一个新的TCP会话。此外，服务器可以使用现有的链接向客户传递信息。
表示状态传输模型得到了浏览器的广泛支持，因为它整合了HTTP 1.1。HTTP 1.1，即REST ，对每次查询都使用TCP握手方法。 REST 由于握手需要时间，因此API经常有延迟问题。
有效载荷数据结构
如果我们在看有效载荷数据结构的同时看 gRPCvsREST 。 gRPCAPI在设计上使用协议缓冲器来序列化有效载荷数据。这种方法更轻，因为它使信息更小，并允许高度压缩的结构。协议缓冲区是二进制格式的，因此，对于数据交换，它对信息进行序列化和反序列化。Protobuf可以自动将大量书写的信息翻译成客户端和服务器编程语言。
REST然而，大多使用JSON 或XML形式来传递和接收信息。JSON 是使用最广泛的格式，因为它的适应性和沟通动态数据的能力，无需遵守精确的结构，尽管它不需要任何结构。JSON的人类可读性是另一个重要的优势，这一点Protobuf还无法比拟。
JSON 然而，一旦涉及到数据传输，JSON就没有那么快或那么轻。这是由于在使用 时，需要将 串行化并翻译成服务器和客户端使用的编程语言。这是数据传输过程中的一个额外步骤，可能会损害效率并增加出错的可能性。REST JSON
代码生成
工程师们必须使用第三方工具（如Postman）来生成API查询的代码，因为，与此不同的是 gRPC，REST API缺乏内置的代码生成设施。与此相反的是。 gRPC由于它的protoc 编译器支持许多编程语言，因此提供了本地代码生成功能。代码生成对于那些结合了在多个平台和语言上创建的众多服务的微服务来说特别有利。总的来说，其内置的代码生成使构建软件开发工具包--SDK--更容易。
REST 另一方面，API不提供原生代码生成功能。你必须利用第三方程序，为几种语言的API调用产生代码生成。虽然这并不麻烦，但重要的是要注意到 gRPC并不依赖任何其他服务来生成代码。
何时使用REST APIs
当比较 gRPC与REST ，在整合建立在微服务上的基础设施时，最广泛采用和最受欢迎的API是REST API。 REST 在很长一段时间内，API可能会继续成为应用连接的默认选项，无论你是创建一个内部网络还是一个向世界其他地方开放其资产的开放平台。 REST API也是需要快速迭代和HTTP协议标准的系统的完美选择。
REST API可以成为你的网络服务开发、微服务和应用程序接口的首选，因为第三方技术普遍支持它们。与之不同的是 gRPC，它有广泛的浏览器支持，并不限于私人系统。这可以使REST APIs在许多情况下非常有用。
它也更容易学习REST ，因为它在互联网上有大量的API文档。如果你的时间很紧，这种更简单的学习曲线是非常重要的。你可以节省大量的研究和学习时间，并立即开始实施。RESTful APIs也更容易集成到应用程序中。它们也提供更好的可扩展性。如果你想很快扩展你的应用程序，使用REST APIs可能更好。在某些应用中，缺乏状态和保密性会导致表征状态转移的问题。如果你的应用程序有一个支付选项。 gRPC可能是一个更好的选择。
何时使用 gRPCAPIs
在两个 gRPC与REST ，大多数第三方工具仍然没有提供内置的功能来满足 gRPC合规性。因此。 gRPCAPI大多被用来创建外部用户无法访问的内部系统或结构。考虑到这种限定，以下情况可以利用 gRPCAPIs。
- 微服务连接
gRPCAPI对连接由轻量级微服务组成的架构特别有帮助，由于其低延迟和快速带宽通信，消息传递的有效性至关重要。
- 多语言系统
gRPC由于其对广泛的编程语言的原生代码生成能力，gRPC擅长处理多语言环境下的通信。
- 实时流
如果需要进行实时通信，由于gRPC具有处理双向流的能力，你的系统可以实时传输和接收数据，而不必等待Unary客户端-响应的互动。
- 低功耗和低带宽的网络
这样的网络可以从gRPC对序列化Protobuf会话的使用中获益，因为它们提供了轻量级的通信，提高了效率和快速性。例如，一个可以从该API中获益的网络是物联网。 gRPCAPI的网络是物联网。
AppMaster 有何帮助？
近几十年来，编程发生了很大的变化，新的技术和框架使开发者的任务变得更容易。No-code 代将这一目标提升到了新的水平。人们不必经历陡峭的学习曲线，可以通过 等平台更快地开发应用。 no-code像AppMaster 。
AppMaster 帮助你根据你的应用程序的具体需要从头开始创建源代码。生成的代码将属于你，你可以根据你的需要修改它。你可以用 ，创建你的应用程序所需要的各种模块。这比让整个开发团队做同样的事情要省钱和省时得多。AppMaster
开发人员可以在后端微服务架构之间发送查询，使用 gRPC协议，使用AppMaster的no-code 生成平台。我们将把API添加到 gRPC网络服务开发以及 gRPC移动应用程序，以增加 gRPC支持。
结论
在过去的API开发中，表征状态转移是常用的方法。但在 gRPCvsREST 。 gRPCAPI正慢慢变得越来越流行。尽管有各种特点使其脱颖而出，但一些问题，如缺乏浏览器支持和API文档，使其难以到处采用。然而，随着技术的进步和社区的发展，我们可以希望 gRPC将克服今天的挑战。
最后，在REST 或 gRPC，甚至任何其他的API方法，如GraphQL 或SOAP，取决于你项目的具体需求。有些应用可能需要 所提供的好处，而有些应用可能需要 所提供的基本功能。 gRPC提供的好处，而其他的可能需要REST 提供的基本功能。你需要评估你的应用程序的功能和用例，以便在这两种有能力的技术之间做出选择。
