我发现越来越多的软件组织在其面向服务的体系结构中使用gRPC，但人们还在使用REST。在哪些用例中使用gRPC是有意义的，以及何时使用REST进行服务间通信是有意义的？REST vs gRPC：我应该什么时候选择一个呢？
有趣的是，我遇到过使用REST和gRPC的开源项目。例如，Kubernetes和Docker Swarm在某种程度上都使用gRPC进行集群协调，但也暴露了REST API与主/节点进行接口连接。为什么不上下使用gRPC？
根据gRPC的future roadmap，人们将继续迁移到它并让REST（通过HTTP）“安静”。
GRPC是更方便在许多方面：
在任何情况下，你将不得不处理所有的GRPC烦恼也因为没有在这个世界上是infalible，但到目前为止，“看起来比REST更好“，并且实际证明了这一点。
我认为你可以拥有两全其美。无论如何，gRPC在很大程度上遵循HTTP语义（通过HTTP/2），但明确允许全双工流式传输，与典型的REST惯例不同，因为它在呼叫调度期间由于性能原因使用静态路径作为从路径解析呼叫参数 - 查询参数有效载荷主体增加了延迟和复杂性。
REST的承诺一直是uniform interface。一个理想的REST客户端将能够与广泛的RESTful资源进行对话，甚至是那些客户端编码时不存在的资源。
不幸的是，除了REST的原始案例 - 人类可读文档的万维网外，这种理想从未真正实现过。
在这一点上，大多数自称为“RESTful”的接口实际上是一种巴洛克式的RPC，其中请求和响应数据在方法，查询字符串，头部，状态码，有效载荷等方面都被抹黑格式。
大部分在今天的“REST风格”界面的统一性是在开发商头上。他们“知道”POST /orders/可能会添加新订单。但是他们仍然需要对客户进行编程，以“知道”他们所谈论的每个API都经常犯很多错误。
尽管如此，还是存在一些在代码中实际可用的一致性。例如，如果您有一个“RESTful”API，那么您通常可以几乎免费地向其添加一个透明的，可调整的缓存层。这是可能的，因为（语义上正确的）HTTP消息已经包含了缓存所需的所有标准化信息：请求方法，URL，状态代码，Cache-Control,Vary以及所有这些。在gRPC中，你必须推出你自己的缓存。
但是，“REST”目前的主导地位的真正原因不是这种次要的可供性。这只是万维网的成功。在历史的某个时刻，人们发现每个人都已经拥有了一个高性能，灵活的HTTP服务器（用于他们的网站）和一个可靠的HTTP客户端（用于查看该站点），因此当人们开始添加机器可读资源时，它坚持相同的HTTP方式更简单，更便宜。他们使用HTTP方法和标题和状态代码，因为这是他们的Web服务器已经理解和记录的。像PHP这样的工具可以让他们在常规Web站点上实现零配置。
如果与万维网的一致性和一致性对您并不重要，那么RPC是一个久经考验的真正的架构选择，而gRPC是一个可靠的实现，可以为您节省一些麻烦，正如ɐuıɥɔɐɯ所解释的。
当正确完成时，REST以性能为代价提高了长期可扩展性和可扩展性，并增加了复杂性。 REST非常适合于必须独立开发和维护的服务，如Web本身。客户端和服务器可以松散耦合，并且不会相互破坏而改变。
RPC服务可以更简单，性能更好，但要以灵活性和独立性为代价。 RPC服务非常适合客户端和服务器紧密耦合并遵循相同开发周期的环境。
但是，大多数所谓的REST服务根本不遵循REST，因为REST成为任何类型HTTP API的流行词。实际上，大多数REST API紧密耦合，因此它们不提供RPC设计的优势。
鉴于此，我有点玩世不恭的回答你的问题是：
有些人采用GRPC他们几年前采用REST同样的原因：设计按流行语。
很多人都在意识到他们实现REST的方式总是等于RPC，所以为什么不使用标准化的RPC框架并正确实现它，而不是坚持使用差的REST实现？
REST是针对跨越多个组织并具有长期目标的项目中出现的问题的解决方案。也许人们意识到他们并不需要REST并寻找更好的选择。
P.s.我应该澄清，我并不期待一个真实的，大部分是正确的答案，而是围绕着开发者在接近这些技术选择方面的经验进行讨论。 – nmurthy