如何跨各种调用方法一致地访问 AWS lambda 有效负载

Question

根据我阅读的 AWS 文档，我看到访问 AWS Lambda 函数有效负载的不同方法，从而导致不同且不兼容的实现。

通常，根据 AWS 文档和实际实验，以 lambda 基于

area

和

length

计算

width

的示例，我们需要不同的实现来支持这两种调用：

aws lambda invoke  --function-name $MY_LAMBDA_NAME \
    --payload '{"length": 10, "width": 10}' \
    --cli-binary-format raw-in-base64-out /dev/stdout

并且：

curl $MY_LAMBDA_URL -H 'Content-Type: application/json' \
    -d '{"length": 10, "width": 10}'

例如，在Lambda 入门中，

event

是一个包含负载的 JSON 文档。该文档指定“如果您的函数由另一个 AWS 服务调用，则事件对象包含有关导致调用的事件的信息”。通过控制台、aws cli 等调用 lambda 时，提供的示例实现按照文档记录工作。通过curl、postman 等调用 lambda 时，它不起作用。访问

length

和

width

如下所示：

def lambda_handler(event, context):
    length = event["length"]
    width = event["width"]
    ...

在其他 AWS 文档页面中，负载是可通过

event

body

访问的字符串。 教程：使用函数 URL 创建 Lambda 函数就是这样一个示例。提供的示例实现在通过curl、postman等调用lambda时有效。但是，当通过控制台、aws cli等调用lambda时，它将失败。在这种情况下，访问

length

和

width

看起来像这样（概念上）从节点转换为Python）：

def lambda_handler(event, context):
    # requires more work to check for encoding, etc.
    body = json.loads(event["body"])
    length = body["length"]
    width = body["width"]
    ...

除了什么都不做之外，我可以想到两种明显的方法来解决这种差异：

1. 记录 lambda 以告诉用户 lambda 是否打算通过其他 AWS 服务使用，并让那些错过文档这一部分的人找出特定密钥在

   event

   中不可用的原因，并且为什么行为会随着上下文而变化
2. 根据

   event

   的内容添加额外的代码来支持这两种用例（基本上检查它是否包含

   body

   ，支持各种编码等）

第一个选项并不令人满意，因为它会带来不必要的维护麻烦。第二个选项很笨重，对于没有阅读过文档这一部分的开发人员来说可能会陷入困境。

解决这种差异的合理选择是什么？ AWS 文档中是否有部分提供了好的建议？有没有办法配置 AWS lambda 来消除差异？是否有方法可以调用 lambda 来实现一致的行为，无论是否通过其他 AWS 服务调用？

Answer 1

AWS Lambda 函数通常是在明确了解通过

event

传递给它们的数据的情况下编写的。您很少会编写一个接收不同类型输入的函数。

这就像 Python 程序中的普通“函数”一样——函数是为了接受特定输入并执行特定操作而编写的。您很少会在 Python 中编写一个函数，该函数必须弄清楚给定的输入是什么以及它对这些输入有何作用。

在您的示例中，如果该函数旨在计算矩形的面积，那么它将期望

length

和

width

作为输入。它不知道如何处理创建新对象时 Amazon S3 生成的事件，也不应该知道 - 该函数的目的是计算矩形的面积，而不是响应新对象的创建。

就像任何编程语言中的函数定义一样，了解输入对于能够编写函数非常重要。

如果您对传递给函数的内容感到困惑，可以在

print(event)

函数的开头添加

lambda_handler()

。这会将事件的内容输出到日志中。您可以使用 CloudWatch Events 查看日志并查看传递给函数的内容。