defaultMethodOptions in SpecRestApi is confusing

[john-tipper]

The documentation states about defaultIntegration:

An integration to use as a default for all methods created within this API unless an integration is specified.

Yet when I define an API with no integration defined within the OpenAPI spec, the default integration is ignored and an error occurs when deploying.

Reproduction Steps

SpecRestApi openapiRestApi = SpecRestApi.Builder.create(this, "MyApi")
						.restApiName("MyApi")
						.apiDefinition(ApiDefinition.fromAsset("openapi.yaml"))
						.defaultIntegration(LambdaIntegration.Builder.create(myLambda)
									.proxy(false)
									.build())
						.deploy(true)
						.build();

where myLambda is a lambda defined earlier in the CDK.

The OpenApi spec has a single method defined (the header and model are not shown):

paths:
  /items:
    get:
      summary: List all items.
      responses:
        '200':
          description: OK
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ItemList'

Error Log

The following error appears in the CloudFormation events when deploying:

No integration defined for method (Service: AmazonApiGateway; Status Code: 400; Error Code: BadRequestException; Request ID: 56113150-1460-4ed2-93b9-a12618864582)

Environment

• CLI Version : 1.42.0
• Framework Version: 1.42.1
• Node.js Version: v12.16.0
• OS : Windows
• Language (Version): Java

Other

---

This is 🐛 Bug Report

[john-tipper]

This could simply be me not reading the documentation correctly, but on first pass, I think the documentation suggests that I shouldn't need to define anything with x-amazon-apigateway-integration inside the OpenAPI spec if there is a default integration specified within the SpecRestApi.

If I need to specify a lambda within a x-amazon-apigateway-integration stanza in my OpenAPI spec then I don't see how to do this if the lambda is also defined as part of the CDK stack as it seems like a chick-and-egg problem.

[isaacliu]

Observed same problem today with CDK 1.42.0 (build 3b64241).

The 'defaultIntegration' was ignored when create new 'SpecRestApi'. Specified AwsIntegration was not picked up and result error ('No integration defined for method') when deploy and failed.

[nija-at]

This will be fixed with #8270.

However, note that, the defaultIntegration option and others similar will only apply to Methods and Resources defined in the CDK. They will not apply to the Resources and Methods in the OpenAPI spec.
As suggested by @john-tipper, you will need to configure these in the spec directly using the APIGateway extensions.

[mmuller88]

Mhh it doesn't look like that the chick-and-egg problem is solved. I can't see that the code handles that somehow. I worked around that with deploying two times and doing a json merge to have the x-amazon-apigateway-integration into the spec. I described it in the Workaround section here: https://martinmueller.dev/cdk-swagger-eng/ but yeah is kind of hard to explain.

[gregorypierce]

I'm still seeing this as well, just in Typescript.

I am creating a LambdaFunction and a LambdaIntegration for that function so that they can be the default handler. If I give that toa SpecRestApi, it just ignores it and throws an exception:

No integration defined for method (Service: AmazonApiGateway; Status Code: 400; Error Code: BadRequestException; Request ID: fcf92d52-dab4-4c7e-9b0c-598f77ed5ba3)

[nija-at]

Re-opening to investigate.

[nija-at]

Re-reading some of the comments here.

The CDK does not open and read the OpenAPI definition files. This means that any value provided under defaultIntegration or any other property in the CDK application will only apply to Methods and Resources in the CDK app. We are not able to (and currently do not) apply these to the Methods and Resources defined in the OpenAPI definitions.

Perhaps having a defaultIntegration property on SpecRestApi is creating this confusion. Would it be less ambiguous if this property was removed entirely and users had to explicitly define the integration for each API?

If I've misunderstood and this is not what you're trying to do, could you please clarify and provide code examples for reproduction?

[john-tipper]

This means that any value provided under defaultIntegration or any other property in the CDK application will only apply to Methods and Resources in the CDK app. We are not able to (and currently do not) apply these to the Methods and Resources defined in the OpenAPI definitions.

@nija-at Actually, I think it might just be fine to call this out clearly in the documentation, as I had interpreted the name defaultIntegration to mean exactly that, i.e. if I do nothing then it is the integration used, come what may, whereas it is only ever used if the API is defined using CDK Methods and Resources.

@mmuller88 I got around the chicken and the egg problem by templating the API spec, rather than having to do two deployments and I used Mustache. So, for a CDK defined API in Java, I added this to the dependencies:

implementation 'com.github.spullara.mustache.java:compiler:0.9.6'

Then, within the API spec, I defined things like:

x-amazon-apigateway-integration:
uri: "{{restapi-lambda}}"
passthroughBehavior: "when_no_match"
httpMethod: "POST"
type: "aws_proxy"
credentials: "{{restapi-role}}"

Finally, within the CDK definition, I did this:

Map<String, Object> variables = new HashMap<>();
variables.put("restapi-lambda", String.format(
    "arn:aws:apigateway:%s:lambda:path/2015-03-31/functions/%s/invocations",
    props.getEnv()
       .getRegion(),
    myRestHandler.getFunctionArn()));
variables.put("restapi-role", apiGatewayRole.getRoleArn());

Writer writer = new StringWriter();
MustacheFactory mf = new DefaultMustacheFactory();

Object openapiSpecAsObject;
try (Reader reader = new FileReader(new File("openapi.yaml"))) {
  Mustache mustache = mf.compile(reader, "OAS");
  mustache.execute(writer, variables);
  writer.flush();

  ObjectMapper yamlMapper = new ObjectMapper(new YAMLFactory());

  openapiSpecAsObject = yamlMapper.readValue(writer.toString(), Object.class);

}

SpecRestApi openapiRestApi = SpecRestApi.Builder.create(this, "MyRestApi")
                        .restApiName("MyApi")
                        .apiDefinition(ApiDefinition.fromInline(openapiSpecAsObject))
                        .deploy(true)
                        .deployOptions(StageOptions.builder()
                                       .stageName("prod")
                                       .build())
                        .build();

I found some bizarre dependency issues that sometimes cropped up where the deployment seemed to happen before the Lambda permissions had been created and then the ApiGateway would not be able to invoke the functions, even though the permissions had been set. I'd have to re-deploy the API in the console in order to have the permissions set correctly, so I can only assume that the ApiGateway, when it creates a deployment, takes a copy of the Lambda permissions as they exist at that moment of deployment, and any subsequent changes have no effect. To get around this, I needed to do the following:

CfnPermission restPermission = CfnPermission.Builder.create(this, "GrantPermissionToApiGateway")
									.action("lambda:InvokeFunction")
									.principal("apigateway.amazonaws.com")
									.sourceArn(String.format(
											"arn:aws:execute-api:%s:%s:*",
											props.getEnv()
												 .getRegion(),
											props.getEnv()
												 .getAccount()))
									.functionName(myRestHandler.getFunctionName())
									.build();


openapiRestApi.getNode()
	  .addDependency(apiGatewayRole);

openapiRestApi.getNode()
	  .addDependency(restPermission);

openapiRestApi.getDeploymentStage()
	  .getNode()
	  .addDependency(restPermission);

[gregorypierce]

I think it creates some confusion only because there is some assumption that it helps with defining the required pieces for OpenApi. Removing it would make it clearer that there is no functionality there and folks need to, unfortunately, roll their own solution. Maybe an example of how it's intended to work would help. There are a lot of people parsing the spec and inserting tokens and such. Is that what we are expected to do? If so, simply saying that would help people understand the intent. I personally intend to do that under the assumption that if I push tokens from the synth process into a document that will be passed to apigateway that cdk will substitute the tokens along the way. As such I'm generating the integrations in memory and plan to insert function arns and the like along the way - then pass that token filled doc to the restapi. It appears that I will get all the function deploys before the restapi is generated so - all good ;)

…

On Tue, Jun 30, 2020, 4:51 AM Niranjan Jayakar ***@***.***> wrote: Re-reading some of the comments here. The CDK does not open and read the OpenAPI definition files. This means that any value provided under defaultIntegration or any other property in the CDK application will only apply to Methods and Resources in the CDK app. We are not able to (and currently do not) apply these to the Methods and Resources defined in the OpenAPI definitions. Perhaps having a defaultIntegration property on SpecRestApi is creating this confusion. Would it be less ambiguous if this property was removed entirely and users had to explicitly define the integration for each API? If I've misunderstood and this is not what you're trying to do, could you please clarify and provide code examples for reproduction? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#8347 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXNUTCOCDYXDW4N4E5TXDRZGYRLANCNFSM4NR34JDA> .