aws-lambda - Lambda 集成与 Lambda 代理 : Pros and Cons

Question

您认为在 AWS API Gateway 中使用和不使用代理功能的 Lambda 集成(更具体地说，在使用无服务器框架时)的优缺点是什么？到目前为止，这是我的想法:

Lambda 与代理集成

亲 : 可以快速原型(prototype)和编码，而无需担心所有需要的配置细节(以及重新发明一些轮子，如通用模板映射等)。

亲 :返回任何状态代码和自定义 header 确实很容易，同时还有一种通用的方法可以读取请求的正文、 header 、参数。

骗子 :一切都在代码中完成，因此自动生成文档有点困难。依赖项( header 、模型、返回的状态代码)在代码中“隐藏”。

没有代理的 Lambda 集成

骗子 :设置它涉及更多工作，并且此配置可能会在不同资源中重复。

亲 :它允许人们解耦 lambda 接收和返回的内容，以及它如何映射到不同的 HTTP 状态代码、 header 和有效负载。

亲 :非常有用，因为它预先规定了它返回的内容，以及它在 header 和有效负载方面的要求。

亲 :从长远来看，设置所有内容时的艰苦工作很有用，因为可以将所有内容导出到 Swagger，因此其他人可以使用它为其生成不同的 SDK。

你怎么认为？您通常使用 Lambda 代理还是普通的 Lambda 集成？你更喜欢什么，为什么？

编辑 :到目前为止，由于提到的原因(解耦和声明依赖项- header 、状态代码等-预先)，我倾向于始终选择不使用代理功能。

Answer 1

(编辑:如评论中所述，我在 2018 年提到的 AWS 措辞已被删除。也就是说，我对 Lambda 代理与自定义集成的想法仍然成立。)
它看起来像 AWS recommends choosing Lambda Proxy Integration for new API development .

Note

The Lambda custom integration, formerly known as the Lambda integration, is a legacy technology. We recommend that you use the Lambda proxy integration for any new API. For more information, see Build an API Gateway API with Lambda Proxy Integration

我知道使用代理集成而不是自定义集成来启动 API 端点和 lambda 集成要“更快”得多(在短期内)，但我很惊讶这是对所有 API/Lambda 开发的建议:

我认为 API Gateway 负责处理“HTTP 详细信息”。使用代理集成将(至少一部分)责任强制到 Lambda 函数上。 (即知道如何解释和决定 HTTP header 、查询参数、状态代码等)

在这样做时，我觉得它混淆了支持 Lambda 函数的责任——Lambda 现在需要处理它被调用的任何“业务”逻辑，还需要处理解释传入的 HTTP 值并决定传出的 HTTP 响应值(value)观。

当然，您可以实现一个额外的 Lambda 函数层来抽象出 HTTP 详细信息，但这不就是 API Gateway 应该做的吗？

它降低了在服务 HTTP 请求之外的上下文中重复使用任何给定 Lambda 函数的能力，除非非 HTTP 客户端将请求格式化为 HTTP 请求。