我们都知道，客户端-服务器架构将通信分为两部分：一部分承担所有繁重的工作并提供服务，称为服务器，另一部分享受这些服务的人称为客户端。
在典型的客户端-服务器通信中，客户端只是向服务器发送资源或服务的请求，然后服务器响应该请求。
对于客户端-服务器通信，客户端和服务器需要具有能够理解它们与之通信的协议的库。 协议是用于互联网通信的一种语言或一组规则。 它们是传输机制，遵循一些通过 Internet 传输数据的准则。
客户端通信的第二个最重要的方面是客户端和服务器都可以识别的消息格式。 此消息格式遵循一种格式，如果不遵循它们就无法进行通信。 消息格式可以类似于 XML（特定表单）或 JSON 文件（必须包含特定的键值对）。 关于这种类型的通信，需要了解的另一个重要方面是它基于请求和响应机制，这意味着服务器仅在客户端发起请求时进行通信。
在 20 世纪初，一种称为 SOAP 的流行客户端-服务器协议将 XML 消息格式与硬编码模式一起使用。 这种消息格式的模式非常严格，并且严格按照指定的规则进行编码，这导致了SOAP的逐渐放弃和REST的出现。 REST的出现是由于j**ascript的日益普及，这也直接导致了json文件格式的流行。 它简单易懂且方便。 它的消息格式只有几个键值对。 简单来说，REST就是使用HTTP作为协议（传输机制）的JSON消息的传输。 使用 REST，我们无需担心如何开发消息传递模式。
我们已经谈到了REST的出现，让我们仔细看看它的核心技术。 我们来看一下定义，REST是一种标准化的软件架构风格，是业界广泛使用的API。
1. REST简单，有一套通信架构标准。 使用 REST，我们不必每次都格式化消息或数据。
2. REST是可扩展的。 如果您的服务变得更加复杂并需要更多功能，您可以轻松地改造服务器端，而无需担心服务器的 REST 性能，并且可以完全隔离地添加新功能。
3. REST是无状态的。 以前，每个请求都携带一些服务器可以理解的信息，服务器的机制允许服务器记住请求的信息，但在REST架构中，会话状态存储在客户端上，这使得服务器效率更高，给服务器带来的工作量更少，从而实现更好的功能。
4. REST是高性能架构，支持缓存。
想象一下，你正在为一家餐厅做一个**。 您可以**获取所有菜单，食物分为三类：
1.开胃菜。 2.主菜。
3.饮料。 现在想**看看所有的饮料。 在REST架构中，我们可以轻松地对这些信息进行分类，并向服务器发送GET请求，以获取饮料的数据。 同样，我们也可以做所有的CRUD（创建、读取、更新、删除），这使得REST适用于不需要超传输数据、不需要实时的大型项目。 REST 对于专注于高效数据传输的应用程序最有效。 缓存是REST的另一个功能，它对标准应用程序很有用，例如食品预订应用程序，酒店预订应用程序，博客，论坛等。
REST功能强大，但也有一些缺点。
1.没有双向通信，如果服务器需要向客户端发送一些数据怎么办？ 在 REST 体系结构中，这是不可能的。 当然，您可以使用一些技巧，但它们不实用。
2. 想象一下获得实时分数**。 您将如何实现此更新分数的功能？ 我们可以让客户端每 10 秒发送一次请求，但这不是一个好的做法。 它使服务器过载，从而降低了服务器响应的效率。
3. REST架构是纯粹的请求和响应，不支持数据流（连续事件处理）。
4. REST无状态属性既有优点也有缺点，因为我们无法判断REST架构上数据的状态。
为了解决REST的第一个问题，即双向通信的需求，WebSocket出现了，它允许服务器发起通信，但是WebSocket的问题在于它没有格式，它只能发送字节，没有任何限制。
websockets本身并没有什么问题，但真正的问题是，任何类型的通信都需要一个协议，并且每个协议都需要一个可以与该协议通信的客户端库（解析数据）。
如果要在基于 REST 的体系结构上创建 Python 应用程序，则需要一个可以与服务器通信的 HTTP 客户端。 在大多数情况下，客户端库是由第三方开发的。 使用第三方库可能会暴露您自己的程序详细信息，不安全，并且整个应用程序将依赖第三方进行通信。
对于 Web 应用程序，浏览器的作用类似于客户端库，但对于非 Web 项目，您需要第三方客户端库。 如果我们自己开发一个应用程序，那就没那么容易了，你将有维护另一个应用程序的负担。
因此，为了解决 REST 的一些问题以及客户端库的问题，Google 在 2015 年发明了 GRPC。
对于 gRPC，Google 为几乎所有流行语言维护了一个客户端库。 它在后台使用 HTTP 2 协议，并使用 Protobuf 作为其消息格式。 我们不需要担心任何客户端库，因为 Google 正在为所有编程语言维护它。 单一的集中式客户端库是 grpc 的主要优势之一。
grpc 的另一个好处是它使用的消息格式。 Protobuf 与语言无关，因此我们可以在 Python 中创建一个客户端，在 Go 中创建一个服务器，并且仍然能够轻松通信。
GRPC 本质上是一个客户端库，也是一种可以在任何设备上使用的协议。
GRPC 使用 Protobuf 进行通信。 它将原型文件序列化为二进制格式并将它们发送到服务器，在服务器端将它们反序列化为原始格式。 同时，GRPC有不同的沟通形式。 可以将它们视为 gRPC 的函数。
单个请求：一种简单的请求-响应通信类型，客户端发送原始请求，服务器在收到请求后等待一段时间以执行某些进程，然后返回一些响应。
服务器流式处理：当发出单个请求时，服务器会使用大量数据进行响应。 例如，当点击某个**时，大量与**相关的数据从服务器端涌出。
客户端流式处理：与服务器流相反。 在这里，客户端一次向服务器发送大量数据。 例如，当您在 Internet 上共享大文件或将图像或 ** 上传到 Internet 时，就会发生这种情况。 客户端不断向服务器端发送数据。
双向流动：在这种类型的通信中，客户端和服务器发送多条消息。 聊天就是一个很好的例子。
根据 gRPC 的功能，假设您要制作一个聊天应用程序。 我们不会使用 REST API，因为它无法允许快速的双向通信流。 ，我们将使用 gRPC 流，这将提供比速度更多的好处。 首先，它的跨语言行为独立于服务器或其他客户端编写的编程语言。 在接受消息格式之前，仍可以建立通信。
因此，借助此功能，聊天应用程序的 Android 版本可以与 iOS 版本进行通信，反之亦然。
有限的浏览器支持：gRPC 使用 HTTP 2，因此很难直接从浏览器调用 gRPC 服务。 有时需要设置**。
不可读的表单：grpc 使用人类无法读取的二进制格式。 在某些情况下，这是一个缺点。
幼稚：gRPC 是在 2015 年开发的，所以与 REST 相比它仍然有点不成熟，有很多错误和问题需要解决。
入职成本：REST和GraphQL使用JSON，更易学。 大多数人会尝试坚持使用它们，因为 protobuf 仍然是一个新颖而复杂的话题，因此很难找到 grpc 专家。
数据格式：
REST使用的消息格式主要是JSON（有时是XML），这种格式更易读，更易于使用。 我们不必担心REST中的模式。 而 grpc 使用协议缓冲区来序列化数据。 压缩形式更轻，携带速度更快。 它采用二进制格式，因此数据在传输过程中被序列化和反序列化。
http 1.1 vs http 2：
REST API 通常使用 HTTP 11 作为其协议，而 grpc 使用 HTTP 2 作为其底层协议。 REST API 也可以使用 HTTP 2，但由于 REST 请求-响应机制，它仍然会受到限制。 GRPC 使用 HTTP 2 并利用 HTTP 2 支持进行客户端响应和双向通信。 这是 grPC 优于 REST 的另一个方面。 它可以像 http 1 一样1 管理单向请求，或同时管理双向请求，如 HTTP 2。
延迟：
grPC 的低延迟和高通信速度使其成为连接由轻量级微服务架构组成的系统的理想选择，从而实现更高效的消息传递。 在大多数网络情况下，REST 延迟需要 25ms，而 grPC 延迟比 REST 小得多。
负载限制：
传输消息时，REST 的最大负载限制为 45MB，而 grPC 没有任何限制，这意味着传输消息可以具有所需的大小。
安全：
在安全性方面，REST落后，因为它使用HTTP 11和JSON格式，易于解密和访问。 另一方面，grPC 使用更安全的 HTTP 2，并使用二进制格式的 Protobuf，难以解密。
速度：
在这里，grpc 再次获胜，因为它比 REST 快 10 倍，出于同样的原因，http 2 被用作协议，protobuf 被用作消息格式。
**生成：
REST 不提供内置的生成功能，这意味着开发人员需要第三方应用程序来生成 API，而 gRPC 具有原生生成功能，这要归功于其与多种编程语言兼容的 ProtoBOF 编译器。 这是另一个好处，特别是对于微服务架构。
最后，我想说的是，REST仍然是最常用和最流行的架构，它不可能放弃。 REST有很多缺点，比如缺乏数据流、没有双向通信、速度慢等，但它最适合我们在日常生活中看到的标准应用程序。 另一方面，grPC 还很年轻，很难学习，它提供了许多功能，例如客户端和服务器端的数据流量都很高，双向数据流良好，快速紧凑，并且使用 HTTP 2。 在性能方面，grPC 最适合高工作负载应用程序，例如流媒体、歌曲流媒体、游戏、文件共享和聊天应用程序。
**10,000粉丝奖励计划