AWS API Gateway 是一项出色的技术,可用于管理和保护对后端 REST API 的访问。但是,AWS 目前支持两种截然不同的技术版本。有什么区别?你应该使用哪一个?

AWS 在其文档中介绍了这两种技术之间差异的基础知识。在本文中,我计划通过讨论一个 API Gateway 版本中缺少的功能可以在另一个版本中得到支持的一些方法来进行更深入的探讨。我还将就使用哪个版本以及何时使用提出一些禁止性的建议。

V1 与 V2:避免严重冲击

AWS 于 2015 年发布了第一个版本的 API Gateway,支持 REST API。在接下来的几年中,AWS 为其 REST API 支持添加了许多功能。其中包括支持通过 Cognito 用户池进行身份验证、通过 VpcLink 公开私有 API 以及金丝雀部署支持等等。

然后在 2019 年,AWS 宣布,根据客户反馈,已开发出新版本的 API Gateway。这个 V2 版本包括对“HTTP APIs”(实际上是 REST APIs)以及WebSocket APIs的支持。 AWS 表示,变更的一个主要目标是简化 API Gateway 模型,并使其更容易开发和部署新的 API。

然而,亚马逊对这个“新”API 网关造成了很多混乱。首先,“HTTP API”是一个奇怪的命名,因为 REST 是一个建立在 HTTP 协议之上的框架。我不明白为什么 AWS 选择了一种让它们听起来像截然相反的命名约定。

其次,名称混淆了它们是同一技术的两个不同版本。如果您查看以下两个地方之一,这只会变得很清楚:

• CloudFormation 语法,其中 REST API 和 HTTP API 语法具有单独的命名空间(AWS::ApiGateway 和 AWS::ApiGatewayV2)。

• AWS 控制台,其中创建 REST API 与 HTTP API 为您提供两种完全独立的用户体验。

以上是 REST API(第一张图片)和 HTTP API(第二张图片)用户界面的屏幕截图。如您所见,V1 和 V2 之间有很大的变化。这些变化不仅延伸到 UI 组织,还延伸到可用的功能 - 甚至延伸到每个系统的价格和性能。

也就是说,在决定使用哪个版本的 API Gateway 之前,您应该详细了解 V1 和 V2 的区别。当您在 Web 上研究信息时,请注意确定您正在阅读的功能是否受 REST API、HTTP API 或两者支持。

性能价格差异

REST API 和 HTTP API 之间的主要区别在于性能和价格。简而言之,HTTP API 是两者的赢家。

REST API 和 HTTP API 都只对实际发出的请求数加上从 AWS 传出的数据收费。但是,定价差异很大。 REST API 将使您每 100 万个请求运行 3.50 美元,外加传出数据的费用。相比之下,对于前一百万个请求,HTTP API 每个请求的成本仅为 1.00 美元,之后每百万个请求的成本为 0.90 美元。这是高达 71% 的价格差异。

最重要的是,AWS 表示 V2 HTTP API 与 V1 REST 兄弟相比具有显着的性能改进。Cloudonaut 的 Andreas Wittig 运行了一些数字并发现与 REST API 相比,HTTP API 的延迟降低了 14% 到 16%。

正如 Andreas 所指出的,延迟差异并不是那么大。而且很可能其中大部分将被对其他组件(例如您的数据库)的依赖所消除。所以 HTTP API 在价格上是明显的赢家,在性能上是小赢家。

REST API 中的功能(但不在 HTTP API 中)

因此,在定价方面,HTTP API 无疑是赢家。但是,正如我之前提到的,价格并不是一切。如果你得到一些回报,你可以证明更高的成本是合理的。

REST API 和 HTTP API 都具有其他 API 所没有的功能。让我们来看看每一个,从 HTTP API 缺乏的 REST API 功能开始。

金丝雀支持

说实话,我写这篇文章的动机是我想构建一个支持金丝雀的 API 网关部署。我听说 API Gateway 支持金丝雀。由于我是 API Gateway 及其功能的忠实拥护者,因此我急于编写代码。

不幸的是,我开始创建的是一个 HTTP API。想象一下当我意识到 HTTP API 不支持金丝雀部署时我的震惊和失望!这严格来说是 V2 所缺乏的 REST API 的一个特性。

一种解决方法是将 Application Load Balancer 合并到您的架构中。 ALB 还支持加权路由,它允许您实现金丝雀式的部署。将 ALB 与 API 网关一起使用是一种既定模式,可提供额外的安全性,因为您可以将 ALB 托管在私有子网中。然后,您可以使用 API Gateway 中的私有集成和 VPC 链接将 API 请求路由到此私有子网中的终端节点。

这种模式具有限制 Docker 容器暴露于 Internet 的额外好处。您可以将容器完全托管在私有子网中,并仅公开您希望公开的那些 REST 端点。有关实现此模式的更多信息,请参阅 AWS 网站上的这篇文章,其中包含完整的和开箱即用的 CloudFormation 模板。

另一种解决方法是使用 Route 53 的加权路由功能。 (AWS 有关于如何在蓝/绿部署的上下文中执行的文档。)在这种情况下,您将在 API 网关中创建另一个阶段(例如canary)。然后,您将使用加权路由将一定比例的流量路由到金丝雀阶段,在您验证新版本的性能时逐渐转移流量。这将起作用,但由于 DNS 传播延迟,部署可能会很慢。

Web 应用防火墙 (WAF) 支持

AWS 的 WAF为 Web 应用程序提供了更高级别的安全性。使用 WAF,您可以应用预先制作和自定义的流量安全规则,以过滤掉机器人和已知的漏洞利用向量。 WAF 既可以使您的应用程序更安全,也可以减少非法的、浪费带宽的流量。

API 网关支持 WAF。也就是说,如果您使用 REST API。 HTTP API 当前不支持 WAF,并且没有迹象表明何时支持。

如果您使用我上面提到的架构,您可以通过在私有 Application Load Balancer 上打开 WAF 来解决此问题。 ALB 支持 WAF,这意味着您可以在享受 WAF 的好处的同时,仍然享受 HTTP API 的更低成本和更高性能。

支持 AWS X-Ray

X-Ray 是 AWS 为您的代码添加跟踪和调试工具的服务。使用 X-Ray,您可以监控代码和服务性能、报告错误并解决影响调用者的问题的根本原因。

REST API 具有选中按钮支持,可将 X-Ray添加到 API 网关调用。遗憾的是,在撰写本文时,HTTP API 中不存在此功能。

对于使用他们的一个自制跟踪选项或像New Relic这样的商业选项的团队来说,这不是什么大问题。其他人仍然可以通过他们的编程语言的 AWS 开发工具包或通过 AWS CLI 直接从他们的代码中使用 X-Ray。因此,虽然这是一个不错的选择,但它不一定会破坏交易。

REST API 中的功能(但不在 HTTP API 中)

更好的程序化模型

编程模型是 HTTP API 大放异彩的一个领域。 AWS 创建 HTTP API 的公开动机之一是 REST API 过于复杂。 HTTP API 在控制台中使用简化的编程模型和改进的新用户界面。

此外,HTTP API 支持 REST API 不支持的几个易于使用的开发功能,包括直接支持 CORS 配置、自动部署以及默认阶段和路由。但是,REST API 确实支持一些开发功能,例如请求正文转换,在撰写本文时 HTTP API 不直接支持这些功能。

但是,REST API 以一种关键方式使开发更容易:它们支持从 Swagger 和其他 API 定义/文档工具支持的OpenAPI定义导入 API 定义。 HTTP API 只能导出到 OpenAPI。

私有集成

私有集成允许 API Gateway 公开托管在私有 VPC 中的资源。使用私有集成,您可以在私有子网中托管 API 源(例如 Docker 容器),同时仅公开您希望通过 API Gateway 公开公开的端点。这导致增强的安全性。

HTTP API 包含对应用程序负载均衡器、网络负载均衡器和 AWS Cloud Map 的全面支持。支持通过 VPC 链接启用,它允许您创建从 API 网关到私有子网的路由。 VPC Link 易于在控制台和 CloudFormation 中配置和分配。 (您可以在此处找到一个有效的 CloudFormation 示例。)

REST API 仅支持网络负载均衡器。此外,配置不像使用 VPC Link 那样简单。

私有集成不应与私有 API混淆。借助私有 API,您可以使用 API Gateway 定义仅可通过 VPC 使用的 API。对 API 的调用保留在 VPC 内,从不通过公共 Internet 进行路由。只有 REST API 支持私有 API。

原生 OpenID 连接 / OAuth 2.0

最后,HTTP API 原生支持 OpenID Connect 和 OAuth 2.0。这是 REST API 本身不支持的一种身份验证框架。

当然可以在 REST API中实现您自己的 OAuth 2.0 支持。但这比仅使用 HTTP API 的本机支持要重得多。

用哪个?

还有一些其他的功能差异我没有在这里介绍。最好熟悉文档,看看你会得到什么 - 以及你会错过什么 - 通过选择一个而不是另一个。为了让事情变得更容易,这里有一个表格格式的快速总结:

如您所见,HTTP API 在功能支持方面还有一些工作要做。另一方面,HTTP API 更加经济、高效且易于使用。

在我看来,如果 REST API 选择了一些可以简化管理并缩短上市时间的关键功能(例如,OpenAPI 导入),您可能会选择使用 REST API。但是,HTTP API 的整体改进使其成为大多数项目的默认选择。您可以毫不费力地直接实现 REST API 独有的大部分功能。此外,随着 AWS 继续投资于这项新服务,您将受益于未来的可用性、价格和性能改进。

标题图片来源:Unsplash