Несколько уроков по интеграции лямбда-прокси API Gateway
- API-шлюз развертывается на разных этапах, а ARN для API-шлюза на этапе v на тестовой консоли несколько отличается. (по крайней мере, это то, что я получил на выходе terraform)
Столько документации и исправлений для проблемы предлагает явно настроить подробный путь как "arn:aws:execute-api:region_name:account_id:${aws_api_gateway_rest_api.api_resource.id}/*/*"
Настроенный источник с предоставленным разрешением доступа
arn:aws:execute-api:region:accountid:fu349z93pa/*/*
Из документации Terraform
Для "${aws_api_gateway_deployment.deployment_rsc_name.execution_arn}"
Сконфигурированный источник с предоставленным разрешением на доступ
arn:aws:execute-api:region:accountid:fu349z93pa/stage/*/*
Если вы тестируете с консоли API Gateway, вы в конечном итоге получите ту же ошибку, и вам придется вручную добавить разрешение для лямбды или повторно выбрать имя лямбда-функции на консоли интеграции методов (что делает то же самое). Это настраивает 2 шлюза API для доступа к Lambda. (один с /stage
развернутым ARN, а другой /*/METHOD/*
- used for test console
)
Но если вы тестируете API-шлюз из ARN рабочей среды на почтальоне, он работает так же хорошо, без каких-либо ручных обновлений инфраструктуры, созданной с помощью terraform. И в большинстве случаев это тот, который имеет значение.
- Даже после исправления первой ошибки вручную / не второй вызов
Malformed response from lambda
Это довольно легко и хорошо задокументировано. AWS Doc
Все, что нам нужно сделать, это обновить лямбду, чтобы ответить указанным форматом.
для. например добавить ниже
callback(null, { "statusCode": 200, "body" : JSON.stringify(sampleResponseJSON) }); on lambda `js`
Как только он работает от начала до конца, мы всегда можем добавить сценарии обработки ошибок.
Надеюсь, это должно сэкономить время для начинающих, таких как я.