架构决策记录:API 使用 JSON 还是 gRPC

状态

已接受

背景

我们正在为一项将被多个客户端使用的新服务设计 API。我们一直在考虑实现该 API 的两种方案:基于 HTTP 的 JSON,或 gRPC。

基于 HTTP 的 JSON 是构建 API 时被广泛使用的方式,许多编程语言和框架都支持它。这种方式简单、轻量且易于理解,是许多项目的好选择。然而,它的效率可能低于其他方案,尤其是在处理大量数据时。

另一方面,gRPC 是一项较新的技术,提供了一种更高效的 API 构建方式。它使用二进制序列化来传输数据,可能比使用 JSON 更快、更紧凑。gRPC 还支持双向流,因此是实时应用的好选择。

决策

在权衡了两种方案的利弊之后,我们决定为我们的 API 使用 gRPC。虽然基于 HTTP 的 JSON 是更简单的方案,但我们相信 gRPC 将为我们的服务提供更高效、更具可扩展性的解决方案。我们还预计我们的 API 将处理大量数据,而 gRPC 的二进制序列化对这种场景会更高效。

此外,我们相信 gRPC 对双向流的支持,将有利于我们将来可能开发的实时应用。

后果

选择 gRPC 之后,与使用基于 HTTP 的 JSON 相比,我们需要使用另一套工具和库来构建 API。这可能需要额外的时间和精力来学习和实现这些技术。此外,想要使用我们 API 的客户端需要使用兼容 gRPC 的库,而这些库的受支持程度可能不如基于 HTTP 的 JSON 库那样广泛。

不过,我们相信使用 gRPC 的好处超过这些潜在的缺点,并且我们有信心这一决策将带来更高效、更具可扩展性的 API。