REST vs gRPC：我应该何时选择其中一个？

Question

我看到越来越多的软件组织在其面向服务的体系结构中使用gRPC，但人们仍然在使用REST。在哪些用例中使用gRPC是有意义的，何时使用REST进行服务间通信是有意义的？

有趣的是，我遇到过同时使用REST和gRPC的开源项目。例如，Kubernetes和Docker Swarm都在某种程度上使用gRPC进行集群协调，但也公开了REST API以便与主/领导节点连接。为什么不上下使用gRPC？

Answer 1

如果操作正确，REST会以性能为代价并增加复杂性，从而提高长期可演化性和可扩展性。 REST非常适合必须独立开发和维护的服务，例如Web本身。客户端和服务器可以松散耦合并在不相互破坏的情况下进行更改。

RPC服务可以更简单，性能更好，但代价是灵活性和独立性。 RPC服务非常适用于客户端和服务器紧密耦合并遵循相同开发周期的情况。

但是，大多数所谓的REST服务根本不会真正遵循REST，因为REST只是一种适用于任何HTTP API的流行语。实际上，大多数REST API都是如此紧密耦合，以至于它们没有优于RPC设计的优势。

鉴于此，我对你的问题的一些愤世嫉俗的答案是：

1. 有些人采用gRPC的原因与他们几年前采用REST的原因相同：by-by-buzzword。

2. 很多人都在意识到他们为RPC实现REST数量的方式，那么为什么不采用标准化的RPC框架并正确实现它，而不是坚持不良的REST实现呢？

3. REST是针对跨越多个组织并具有长期目标的项目中出现的问题的解决方案。也许人们意识到他们并不真正需要REST并寻找更好的选择。