Я создавал больший стек CloudFormation с такими ресурсами, как ApiGateway, Lambda и т. д.
Для последней версии ApiGateway я поместил AWS :: ApiGateway :: Methods непосредственно в / (rootresourceid), и при развертывании из CloudFormation Authorizer на AWS :: ApiGateway :: Stage станет AWS_IAM, хотя я установил пользовательский Authorizer в методе и используйте DependsOn, чтобы позволить ресурсам ждать.
Post:
DependsOn:
- AuthorizerApi
Type: AWS::ApiGateway::Method
Properties:
AuthorizationType: CUSTOM
AuthorizerId: !Ref AuthorizerApi
RestApiId: !Ref Api
ResourceId: !GetAtt Api.RootResourceId
HttpMethod: POST
Integration:
Type: AWS_PROXY
IntegrationHttpMethod: POST
Uri: !Join ['', ["arn:aws:apigateway:", !Ref "AWS::Region", ":lambda:path/2015-03-31/functions/", !GetAtt PostLambda.Outputs.FunctionGetAtt, ":${stageVariables.environment}/invocations"]]
MethodResponses:
- ResponseModels:
application/json: Empty
StatusCode: 200
Самое смешное, что это не проблема для ресурсов под rootresource, поэтому, похоже, это проблема наследования.
Кто-нибудь еще, кто испытал это, и каково решение, если требование не состоит в том, чтобы иметь путь под root?
Я думал, что наблюдение было довольно ясным, но при создании методов в ApiGateway с использованием CloudFormation я подозревал, что вполне возможно иметь методы под .RootResourceId, а затем иметь настраиваемый авторизатор на rootresourceid, но когда стек Cloudformation готов, тогда Authorizer имеет тип AWS_IAM, чего я не ожидал, исходя из кода в моем тексте.
если требуется не иметь путь под корнем? - Вы говорите о создании пути ресурса шлюза API, который не находится в пути к корневому ресурсу? или что-то другое