我们都知道的是客户端-服务器架构将通信分为两部分：一部分承担所有繁重的任务并提供服务，称为服务器，另一部分享受这些服务，称为客户端。
在一般的客户端-服务器通信中，客户端只需向服务器发送请求资源或服务的请求，然后服务器响应该请求。
对于客户端-服务器通信，客户端和服务器需要具有能够理解它们进行通信的协议的库。协议是一种语言或一组互联网通信规则。它们是遵循一些通过 Internet 传输数据的准则的传输机制。
客户端通信的第二个最重要的方面就是客户端和服务器都可以识别的消息格式。此消息格式遵循某种格式，如果不遵循这些格式，则不能进行通信。消息格式可以类似于 XML（特定的形式）或 JSON 文件（必须包含特定的键值对）。这种类型的通信需要理解的另一个重要方面是它基于一种请求和响应机制，这意味着服务器仅在客户端发起请求时才进行通信。
REST为什么会出现？
在 20 世纪 90 年代初，一种名为 SOAP 的流行的客户端-服务器协议使用带有硬编码模式的 XML 消息格式。这种消息格式的架构非常严格，严格按照指定的规则来编码，这导致 SOAP 逐渐被放弃，REST 就慢慢出现。 REST 的出现是由于 JavaScript 的日益流行，也直接导致了 JSON 文件格式的流行。它简单易懂且方便。它的消息格式中只有一些键值对。 简单来说，Rest 就是以 HTTP 作为协议（传输机制）传输 JSON 消息。有了 Rest，我们就不需要担心如何制定消息传输的模式。
REST是什么？
上面我们说到了REST的出现，下面我们就来深入了解一下它的核心技术。先看下定义， Rest是一种标准化的软件架构风格，是业界广泛使用的API。
REST 流行和广泛使用的原因
1、REST 对于通信架构来说是简单且有一套标准。使用 REST 时，我们不必每次都格式化消息或数据。
2、REST 是可扩展的。如果您的服务变得更复杂并且需要更多功能，您可以轻松地改造您的服务端，而不必担心服务器的 REST 性能，并且您可以完全隔离地添加新功能。
3、REST 是无状态的。之前每个请求都携带一些被服务端理解的信息，服务端的机制能让服务器记住这个请求的信息，但在REST架构中，会话状态存储在客户端，这使得服务器更加高效，并且给服务器带来更少的工作量，从而实现更好的功能。
4、Rest 是一种高性能架构，并且支持缓存。
什么时候使用REST
想象一下您正在为一家餐厅制作一个网站。您可以在线获取所有菜单，食物分为三类：
1、前菜
2、主菜
3、饮料
现在想在线查看所有饮料。在 Rest 架构中，我们可以轻松的将这些信息进行分类，向服务器发送 GET 请求到可以获取饮料的数据。同样，我们也可以执行所有CRUD（创建、读取、更新、删除），这使得REST适合不需要超级传输数据且不需要实时的大型项目。对于以数据高效传输为主的应用程序，Rest 最有效。缓存是 REST 的另一个功能，对于食品预订应用程序、酒店预订应用程序、博客网站、在线论坛网站等标准应用程序非常有用。
REST的限制和问题
REST很强大，但也有一些缺点
1、不能双向通信，如果服务器需要向客户端发送一些数据怎么办？在 REST 架构中，这是不可能的。当然，你可以使用一些技巧，但它们并不实用。
2、想象一下要实现一个实时比分网站。你将如何实现这个更新比分的功能？我们可以让客户端每 10 秒发送一次请求，但这不是一个好的做法。它会使服务器过载，从而降低服务器响应的效率。
3、REST架构纯粹是请求和响应，不支持数据流（连续的事件处理）。
4、REST 无状态的属性有好处也有坏处，因为我们无法判断 REST 架构上数据的状态。
gRPC 为何出现？
为了解决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是什么？
gRPC 使用 protobuf 进行通信。它将proto文件序列化为二进制格式并发送给服务器，在服务器端将它们反序列化为原始格式。同时 gRPC 有不同的通信形式。您可以将它们视为 gRPC 的功能。
gRPC的功能
单个请求：一种简单的请求-响应通信类型，客户端发送原始请求，服务器在收到请求后等待一段时间以执行某些过程，然后返回一些响应。
服务器流式传输：发出单个请求时，服务器会响应大量数据。例如，当点击某个视频时，大量与视频相关的数据从服务器端涌出。
客户端流式传输：和服务器流式传输相反。这里客户端一次向服务器发送大量数据。例如，当您在互联网上共享大文件或将图像或视频上传到互联网时，就会发生这种情况。客户端不断向服务器端发送数据。
双向流：在这种类型的通信中，客户端和服务器发送多条消息。聊天就是一个很好的例子。
什么时候使用gRPC
基于gRPC的功能，假设想要制作一个聊天应用程序。我们不会使用 Rest API，因为它将无法允许双向通信的快速流。，我们将使用 gRPC 流，这将提供除速度之外的更多好处。 首先，它的跨语言行为与服务器或其他客户端编写的编程语言无关。在消息格式被接受之前，仍然可以建立通信。
因此，通过此功能，Android 版本的聊天应用程序可以与 iOS 版本进行通信，反之亦然。
gRPC的问题
有限的浏览器支持：gRPC 使用 HTTP 2，因此很难直接从浏览器调用 gRPC 服务。有时需要设置代理。
不可读的形式：gRPC 使用人类无法读取的二进制格式。在某些情况下这是一个缺点。
不成熟：gRPC 是 2015 年开发的，所以与 REST 相比还是有点不成熟，有很多 bug 和问题需要解决
上手成本：Rest 和 GraphQL 使用 JSON，更容易学习。大多数人会尝试坚持使用它们，因为 protobuf 仍然是一个新且复杂的主题，因此很难找到 gRPC 专家。
REST vs gRPC
数据格式：
REST 使用的消息格式大多是 JSON（有时是 XML 格式），这是一种更具可读性且更易于处理的形式。我们不必担心 Rest 中的模式。而gRPC 使用协议缓冲区来序列化数据。压缩形式更轻，携带起来更快。它是二进制格式，因此在传输过程中会对数据进行序列化和反序列化。
HTTP 1.1 vs HTTP 2：
Rest API 通常使用 HTTP 1.1 作为其协议，而 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 1.1和JSON格式，易于解密和访问。另一方面，gRPC 使用安全性更高的 HTTP 2，并使用二进制格式的 protobuf，难以解密。
速度：
在这里，gRPC 再次获胜，因为它的速度比 Rest 高 10 倍，而且出于同样的原因，使用 HTTP 2 作为协议，使用 protobuf 作为消息格式。
代码生成：
Rest不提供内置代码生成功能，这意味着开发人员需要第三方应用程序来生成API代码，而gRPC由于其protobuf编译器而具有本机代码生成功能，该编译器与多种编程语言兼容。这是另一个好处，特别是对于微服务架构而言。
结论
最后，我想说的是，REST 仍然是最常用、最流行的架构，不可能放弃。 REST 有很多缺点，比如缺乏数据流、没有双向通信、速度慢等，但它最适合我们在日常生活中看到的标准应用程序。 另一方面，gRPC 还很年轻且难以学习，它提供了许多功能，例如客户端和服务器端的高数据流、良好的双向数据流、快速且紧凑，并且使用 HTTP 2。性能方面，gRPC 最适合高工作负载应用程序，例如视频流、歌曲流、在线游戏、文件共享和聊天应用程序。
如果喜欢这篇文章，点赞支持一下，微信搜索：京城小人物，关注我第一时间查看更多内容！感谢支持！