我有一个REST API，它公开POST端点并接受JSON消息。然后API触发。net Core 3.1中的Lambda函数，该函数对负载进行一些处理。
JSON消息的结构类似于:{
Code: "string",
Name: "string",
Items: []
}
Items的集合可能非常大。
就像以前发生过的许多人一样，我遇到了一些关于有效负载大小的AWS限制。AWS API网关的有效载荷大小限制为10 MB, Lambda函数的有效载荷大小限制为6 MB。
我已经在线查看并阅读了有关使用预签名S3 url的工作，但我不确定这些将在我的场景中工作。
当JSON有效负载中的数据错误或丢失时，我目前使用的API返回400 BadRequest。我不知道如何用预签名的S3 url来模拟这一点，并直接上传到S3。
此外，即使负载在S3中，我仍然需要一个Lambda函数来读取和处理它。
最后，API与第三方集成，所以让他们发布到两个不同的url并不是一个理想的解决方案。
关于如何使API与非常大的JSON消息一起工作的任何想法?
AWS API Gateway的有效载荷大小限制为10mb, Lambda函数的有效载荷大小限制为6mb。
是的，正确，有一些限制。原因是负载作为单个json传递给lambda fn，并且没有更多内存友好型流的选项。如果我们想要慷慨的免费层，我们必须接受一些限制。
我不知道如何用预签名的S3 url来模拟这个并直接上传到S3
它不是模拟相同的场景，需要不同的方法。基本上，客户端将内容上传到S3，并且调用lamba作为关于新内容的S3通知事件(异步)。
示例步骤:
- 客户端调用api获取预先指定的url
- 客户端上传内容
- S3调用lambda fn作为S3事件通知的一部分，作为输入，lambda接收S3对象键，lambda必须读取/下载内容本身。
缺点是，如果客户端期望从处理中得到一些响应，那么请求和处理需要以某种方式配对在一起(使用文件名，使用DB中的一些持久化数据，…)
让他们发布到两个不同的url不是一个理想的解决方案
我们强迫我们的合作伙伴那样工作，然后…它正在起作用。如果您对限制和方法不满意，您可以公开自己的服务器(不是lambda)并执行自己的限制或支持流。
感谢大家的参与。
我们最终做的是让第三方在发送给我们之前压缩他们的JSON。
然后我们解压缩它，将它序列化到原始dto中，并运行Validator来检查模型是否有效。
如果验证失败，我们返回一个带有验证错误的BadRequest()。否则我们返回accept_()