GRPC与REST有何不同？

Question

我正在阅读此explanation of GRPC，这个图表很有意思：

传输层如何工作？如果它通过网络...为什么它被称为RPC？更重要的是，这与为服务层实现API的REST有何不同（客户端中的类具有发出http请求的方法）？

Answer 1

传输层使用HTTP / 2在TCP / IP之上工作。它允许更低延迟（更快）的连接，可以利用从客户端到服务器的单个连接（这可以更有效地使用连接，并可以更有效地使用服务器资源。

HTTP / 2还支持双向连接和异步连接。因此，服务器可以有效地与客户端联系以发送消息（异步响应/通知等）。

虽然REST和gRPC都可以生成客户端/服务器存根（使用诸如swagger for REST之类的东西），但REST有一组有限的主要“函数”调用（或动词）：

+-----------+----------------+
| HTTP Verb |      CRUD      |
+-----------+----------------+
| GET       | Read           |
| PUT       | Update/Replace |
| PATCH     | Update/Modify  |
| DELETE    | Delete         |
+-----------+----------------+

而gRPC可以定义任何类型的函数调用，包括同步/异步，单向/双向（流）等。

使用gRPC，客户端调用本地方法。对于程序员来说，看起来你正在进行本地调用，但底层（自动生成的客户端存根）会将调用发送到服务器。对于服务器来说，它的方法看起来像是在本地调用的。

gRPC负责所有底层管道并简化编程范例。然而，对于一些专门的REST纯粹主义者来说，这看起来似乎过于复杂。 YMMV

Answer 2

REST不需要JSON或HTTP / 1.1

您可以轻松构建一个通过HTTP / 2发送protobuf消息（或其他任何消息）的RESTful服务

您可以构建RESTful服务，以通过HTTP / 2发送JSON

您可以构建RESTful服务，以通过HTTP / 1.1发送protobuf消息

RESTful服务不是HTTP / xx之上的“ hack”，它们是遵循基本体系结构原理的服务，这些原理使任何版本的HTTP成功（例如GET请求的可缓存性和PUT请求的可重播性）。 / p>

gRPC，SOAP等。 Al更像是骇客-HTTP之上的骇客通过HTTP隧道传送RPC样式的服务，从而绕过防火墙和中间盒限制。那不一定是坏事。有时您可能想要RPC样式的服务而不是REST的服务，而我们必须生活在一个很难替换中间箱的世界中。

如果您没有时间阅读REST的实际定义： https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

总是有TLDR；维基百科上的版本：

https://en.wikipedia.org/wiki/Representational_state_transfer

如果您需要RPC样式的服务，那么gRPC确实很棒。如果您想生活在Web上，或者想要RESTful样式服务附带的所有好处，请构建RESTful样式服务。而且，如果在您的静态服务中以JSON格式对数据进行序列化/反序列化太慢，则可以使用protobuf或其他任何方法。

如果gRPC是任何东西的版本2，那么它就是SOAP的版本2。一种不可怕的东西，例如SOAP。

而且，不，您不能只是在GET请求中“调用任何函数”，并拥有RESTful服务。

最后一件事：如果您要通过RESTful服务使用protobuf，请使用内容类型标头等正确执行操作。这样，您就可以轻松支持JSON和protobuf。

现在从我的SOAP框中退出。;）

Answer 3

gRPC优于REST的最大优势是它支持HTTP / 2而不是爷爷HTTP 1.1。那么HTTP / 2优于HTTP 1.1的最大优点是，'HTTP / 2允许服务器“推送”内容'......

Answer 4

我总是觉得gRPC和REST绝对是两个不同的东西。

REST最适合面向资源的服务。 否则我们可以使用gRPC以获得高性能。

REST是Internet级别的，供最终用户与我们的服务交谈。 gRPC是Intranet级别，用于内部服务之间的对话。

REST具有可遵循的应用程序语义。 gRPC没有提供任何内容，您应该从头开始构建所有内容。