Aws-cdk: Add HTTP API support to LambdaRestApi

[adamnfish]

The LambdaRestApi construct provides a concise way of setting up a Lambda function that is exposed as an HTTP server via APi Gateway. By default this sets up a proxy integration that routes requests to the specified handler.

Following the announcement of HTTP APIs for API Gateway, it looks to me like the LambdaRestApi construct should use this type of API Gateway for proxy integrations.
https://aws.amazon.com/blogs/compute/announcing-http-apis-for-amazon-api-gateway/

This change should be transparent to the developer from a technical point of view, with a few caveats (more detail below). However, the pricing model for HTTP APIs mean that developers making use of the proxy LambdaRestApi constructs would see reduced costs.

If backwards compatibility needs to be maintained then instead adding an option to opt-in to the use of an HTTP API would be fine as well.

Use Case

HTTP APIs look great. Simpler and cheaper than current API Gateways gets a :+1: from me.

Most of the documentation and tutorials for API Gateway are simple proxy integrations (and indeed, the LambdaRestApi construct) that would benefit from this change. It certainly feels to me like putting a Lambda function on the internet behind API Gateway without any advanced features (e.g. authorizers, edge-optimised, request transformations) is the most common use case for this construct. CDK's very nature is to be an abstraction over the underlying functionality offered by CloudFormation and here it seems natural to use the simplest (and cheapest) AWS primitive that achieves the goal.

Proposed Solution

Ideally, this would be implemented for any LambdaRestApi that is set up as a proxy integration so developers can transparently take advantage of the reduced costs associated with this resource type. This means the existing proxy boolean construct property would be used to determine if the resulting API Gateway should be an HTTP API by setting the protocolType on the resulting resource to HTTP if true, assuming the API Gateway only uses features supported by HTTP APIs.

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-apigatewayv2-api.html#cfn-apigatewayv2-api-protocoltype
The "Developer experience" section of the feature's announcement documents the use of the protocol-type field to create an HTTP API.
https://aws.amazon.com/blogs/compute/announcing-http-apis-for-amazon-api-gateway/

There are a few caveats to using HTTP APIs for all proxy integrations:

• HTTP APIs do not support all the features of API Gateway so a robust solution should ensure these are not used before choosing to create an HTTP API
• Having the construct select HTTP APIs where possible could result in a "replacement" update for existing stacks after a CDK update that adopts this feature.

Failing that, a new constructor property for LambdaRestApi that allows explicit opt-in to HTTP APIs, perhaps by exposing the protocol type property directly, would be sufficient.

Other

• [x] :wave: I may be able to implement this feature request
• [x] :warning: This feature might incur a breaking change

As above, the ideal implementation would change existing API Gateway resources into HTTP APIs. However, changing the protocolType is a replacement update, which means this change would likely result in a DNS change for existing proxy LambdaRestApis. This may be undesirable in some cases.

I'll be happy to try and help deliver this if needed, although I'll certainly need some support getting started. HTTP APIs are still in beta (with limited region availability) so probably not yet the time to deliver this in the construct just yet, unless you have a process for dealing with features that are not yet GA?

---

This is a :rocket: Feature Request

[bionicles]

5301

HttpApi:
  Type: AWS::ApiGatewayV2::Api
  Properties:
    Name: Lambda Proxy
    Description: Lambda proxy using quick create
    ProtocolType: HTTP
    Target: ${lambda arn}

[pahud]

As HTTP API is still in beta, and aws-apigateway L2 has been stable. Maybe we should create a new construct for that for beta testers?

I was also wondering if we should create a new aws-apigatewayv2 L2 construct or just extend the existing one for all AWS::ApiGatewayV2::* resources.

[bionicles]

it looks like typically in the past, we made a new folder for v2; this may keep implementations simpler

rest apis are super complicated with methods, responses, integrations, templates, tons of stuff. i vote for a fresh start

[nija-at]

Given the significant difference between Rest API and HTTP API, our current approach is to build new constructs for HTTP API in the package aws-apigatewayv2 (see motivation in https://github.com/aws/aws-cdk/commit/d58667e473c1e07ac8f2f073b3a541569a014e01). This will not be part of LambdaRestApi but the features should be available via a new set of constructs.

I'm closing this in favour of https://github.com/aws/aws-cdk/issues/5301 which is tracking overall support for HTTP APIs in the CDK.

Please +1 the other issue to get us to prioritize this feature.