Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(apigateway): add methodresponse support #1572

Merged

Conversation

john-shaskin
Copy link
Contributor

@john-shaskin john-shaskin commented Jan 18, 2019

Add MethodResponse type and the ability to add one or more method responses, when creating an API gateway REST API method.


Pull Request Checklist

  • Testing
    • Unit test added
    • CLI change?: manually run integration tests and paste output as a PR comment
    • cdk-init template change?: coordinated update of integration tests with team
  • Docs
    • jsdocs: All public APIs documented
    • README: README and/or documentation topic updated
  • Title and Description
    • Change type: title prefixed with fix, feat will appear in changelog
    • Title: use lower-case and doesn't end with a period
    • Breaking?: last paragraph: "BREAKING CHANGE: <describe what changed + link for details>"
    • Issues: Indicate issues fixed via: "Fixes #xxx" or "Closes #xxx"
  • Sensitive Modules (requires 2 PR approvers)
    • IAM Policy Document (in @aws-cdk/aws-iam)
    • EC2 Security Groups and ACLs (in @aws-cdk/aws-ec2)
    • Grant APIs (only if not based on official documentation with a reference)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.

@john-shaskin john-shaskin requested a review from a team as a code owner January 18, 2019 17:41
@john-shaskin john-shaskin force-pushed the feature/add-apigateway-methodresponse branch from efc8afd to ed930fe Compare January 18, 2019 18:17
@sam-goodwin sam-goodwin added the feature-request A feature should be added or improved. label Jan 18, 2019
Copy link
Contributor

@sam-goodwin sam-goodwin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the pull! I have reservations about shipping this without support for Models.

/**
* The method response's status code, which you map to an IntegrationResponse.
*/
responseModels?: { [destination: string]: string };
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're going to implement L2 support for method responses, I think we should also support Model, since the value of each key here should be a reference to https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-apigateway-model.html

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed.

},
responseModels: {
'application/json': 'Empty',
'text/plain': 'Empty'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have a use-case where you'll be hard-coding the model names or creating them as part of your stack?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't. My current use-case is just using the default Empty model. Maybe this is worth at least adding an IModel interface, as @RomainMuller mentioned below, and perhaps having some default Empty implementation.

responseParameters?: { [destination: string]: boolean };

/**
* The method response's status code, which you map to an IntegrationResponse.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a mapping of content type to model name, not the status code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Totally grabbed the wrong description from the docs 😛 Will fix that.

Copy link
Contributor

@RomainMuller RomainMuller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @sam-goodwin, it would be awesome if we can push this a little further and have basic support for models, at least to the point the APIs here can be reasonably expected not to change once we make a more comprehensive L2 support for model definition. Maybe it's just a matter of introducing an IModel interface and passing this instead of the model names...

@john-shaskin
Copy link
Contributor Author

Working on getting base level support for referencing an IModel, instead of passing in a hard-coded string for the model name. Just working out some kinks around being able to reference the default Empty or Error models, when you're not defining your own.

@rix0rrr
Copy link
Contributor

rix0rrr commented Jan 21, 2019

Just working out some kinks around being able to reference the default Empty or Error models, when you're not defining your own.

If I may make a suggestion, a default class of class EmptyModel extends IModel might do the trick.

@john-shaskin
Copy link
Contributor Author

Just working out some kinks around being able to reference the default Empty or Error models, when you're not defining your own.

If I may make a suggestion, a default class of class EmptyModel extends IModel might do the trick.

That'll work. I was probably overcomplicating the association to the RestAPI in my head, and thinking I should deal with that. But, it sounds like that's not necessary.

@sam-goodwin sam-goodwin removed the feature-request A feature should be added or improved. label Jan 22, 2019
@john-shaskin john-shaskin force-pushed the feature/add-apigateway-methodresponse branch 3 times, most recently from b3d24c1 to ddcb89f Compare January 23, 2019 05:31
@john-shaskin
Copy link
Contributor Author

I've added a start at models, with IModel. I haven't tried to add full support for models yet. I may look into that next.

@john-shaskin
Copy link
Contributor Author

@RomainMuller and/or @sam-goodwin, any chance you guys have some time to look at the updates on this?

@@ -34,11 +35,15 @@ export interface MethodOptions {
*/
apiKeyRequired?: boolean;

/**
* The responses that can be sent to the client who calls the method.
*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a "@default" clause and describe the behavior if this is not defined

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. I can add that. I'll also look at doing the same for the properties of the MethodResponse type itself.

@eladb
Copy link
Contributor

eladb commented Feb 4, 2019

assigning to @sam-goodwin

@john-shaskin john-shaskin force-pushed the feature/add-apigateway-methodresponse branch 2 times, most recently from be86fed to 1cf909e Compare February 5, 2019 15:15
@john-shaskin
Copy link
Contributor Author

@sam-goodwin, I've augmented the documentation around MethodResponse, as per @eladb's ask.

readonly modelId: string;
}

export class EmptyModel implements IModel {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add docs and provide a link to official documentation describing the keywords 'Empty' and 'Error'.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added some documentation around both the Empty and Error models. As far as reference links, I was able to find some mention in the official docs for the Empty model, but not specifically the Error model (outside of mentioning that Empty and Error are available by default). Are you aware of a page in the documentation that addresses the Error model in any further detail?

@john-shaskin john-shaskin force-pushed the feature/add-apigateway-methodresponse branch 4 times, most recently from 6ac7b17 to c9a77f5 Compare February 6, 2019 00:27
public readonly modelId = 'Error';
}

// TODO: Implement Model, enabling management of custom models.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update README roadmap section

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm adding an issue to track the lack of support for API gateway models, and will quote that in the api-gateway readme.

responseParameters: {
'method.response.header.errthing': true
},
responseModels: {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am wondering if a bunch of static properties on Model to make it “enum-like” would make a nicer and more discoverable API here: “Model.Empty” and “Model.Error”

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I explored adding static properties to a stubbed Model class, but I get an error that the build wants me to have Model implement cdk.Construct, so I backed away for now. Perhaps there's a way to get the build to temporarily ignore that requirement?

Remove Dockerfile that was no longer needed

Update python base image from 3.6 to 3.6.5

Make the dockerfile work

Add MethodResponse support for aws-apigateway

Remove Dockerfile that was no longer needed

Update python base image from 3.6 to 3.6.5

Make the dockerfile work

Add MethodResponse to API Gateway Method.

Add some documentation to the MethodResponse properties. Update the test for MethodResponse with response models.

Fix some formatting and finish adding code documentation for MethodResponse.

Remove Dockerfile from this branch

Fix bad merge to methodresponse test.

Correct the MethodResponse response models documentation.

Add IModel type to reference when configuring a MethodResponse

Slight update to comments.

Update API Gateway MethodResponse documentation.

Author:    John Shaskin <guitarjohnn@gmail.com>
Date:      Mon Feb 05 5:30:45 2019 +0100

Add some documentation around the referencing default Empty/Error models.

Edit documentation around the referencing default Empty/Error models.

Edit documentation around the referencing default Empty/Error models.

Fix 'trailing whitespace' in comments

Add roadmap section with item for adding support for API gateway models
@john-shaskin john-shaskin force-pushed the feature/add-apigateway-methodresponse branch from c9a77f5 to 624bda3 Compare February 6, 2019 19:00
@john-shaskin
Copy link
Contributor Author

@eladb, is there anything else pending on this PR to get it merged?

@sam-goodwin sam-goodwin merged commit 46236d9 into aws:master Feb 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-apigateway Related to Amazon API Gateway
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants