REST和gRPC并排出现在新的Google端点文档中


谷歌在他们的发展和围绕GRPC的故事讲述方面一直在向前迈进。它们的高速速度接近于使用HTTP/2作为传输,使用协议缓冲区(ProtoBuf)作为其序列化消息格式的API。即使有了这些进展,他们也没有把所有做基本web API的人抛在后面,而是在所有新的Google API上积极支持这两种方法,以及在Google Cloud中部署API的服务和工具上支持这两种方法--在他们的平台上并排支持双速API。

当您使用Google Cloud Endpoints来部署和管理API时,您可以选择提供一个更RESTful的版本,以及一个更高级的gRPC版本。他们在服务特性和工具上继续支持这种方法,现在还记录了API。As part of their rollout of a supporting API portal and documentation for your Google Cloud Endpoints, you can automatically document both flavors of your APIs。根据您要解决的用例类型和您要迎合的开发人员类型,为考虑提供两种类型的api提供了有力的理由。

根据我的经验,更简单的web API对于刚刚开始API之旅的人来说是理想的,并且可以满足60-75%的API部署需求。有些组织在他们的API之旅中走得更远,那些提供B2B解决方案的组织,将潜在地需要更高性能,更大容量的gRPC API。这使得谷歌提供的云API基础设施成为一个非常有吸引力的选择,可以帮助成熟的API提供商转换档位,甚至可以帮助人们理解他们将能够在未来的道路上转换档位。您可以得到一个同时支持这两种速度的API部署和管理解决方案,而且其他支持特性,服务和工具(如文档)也可以以这两种速度交付。

通常情况下,我对单一提供者/社区方法来交付API的替代方法持相当怀疑的态度。这也是我对GraphQL持保留态度的原因之一。然而,Google和gRPC已经将HTTP/2投入使用,并且消息传递格式是开源的。虽然谷歌的做法绝对是完全一样的,但他们已经拥抱了网络,这一点我在Facebook领导的GraphQL社区中看不出来。我仍然质疑谷歌的动机,并不是因为他们在做什么见不得人的事,而是我怀疑每家公司在API方面的动机。做了八年,我不相信任何人不是完全自私的。然而,我被调到gRPC已经有一段时间了,我还没有看到任何让我紧张的迹象,他们不断地提供有益的功能,就像他们在这篇文档中做的一样,让我不断地写故事,展示他们正在做的事情。