APIGateway service controller

[vijtrip2]

New ACK Service Controller

Support for APIGateway

List of API resources

List the API resources in order of importance to you:

1) RestApi 2) Integration 3) Resource 4) Stage 5) VPCLink

[vijtrip2]

/lifecycle frozen

[vijtrip2]

I have started generating the initial resources for this service controller.

[cawolf]

Are there any plans on implementing this in the near future?

[giedri]

V2 of the API Gateway does not implement features typically used by the enterprise customers. Most often used features that are missing in the V2 (HTTP) APIs while present in the V1 (REST) APIs are private endpoints, AWS WAF integration, API keys and usage plans, payload transformations. Full comparison of the features of the API Gateway available in the documentation article. Until this feature parity is reached, most of the large customers use REST APIs as they implement features required in their workloads.

[cPu1]

/assign @cPu1

[giedri]

There are couple of resources missing in the list above to make any practical REST API working -

• Deployment that will need to be referred by the Stage (on the list already),
• Authorizer, as most APIs do not allow open access

Rest of the resources listed at https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ApiGateway.html would be needed for the features usually implemented in an enterprise API.

[cPu1]

There are couple of resources missing in the list above to make any practical REST API working -

• Deployment that will need to be referred by the Stage (on the list already),
• Authorizer, as most APIs do not allow open access

Rest of the resources listed at https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ApiGateway.html would be needed for the features usually implemented in an enterprise API.

@giedri, there's also the Method resource required by the Integration resource. We plan on adding the remaining essential resources, including Authorizer and Deployment, as a fast-follow feature.

[giedri]

I also noticed that Body and BodyS3Location are missing in https://aws-controllers-k8s.github.io/community/reference/apigateway/v1alpha1/restapi/ which will prevent developers from using OpenAPI specification to define REST APIs instead of building resource/method by resource/method.

[a-hilaly]

I also noticed that Body and BodyS3Location are missing in https://aws-controllers-k8s.github.io/community/reference/apigateway/v1alpha1/restapi/ which will prevent developers from using OpenAPI specification to define REST APIs instead of building resource/method by resource/method.

cc @cPu1 ^

[cPu1]

I also noticed that Body and BodyS3Location are missing in https://aws-controllers-k8s.github.io/community/reference/apigateway/v1alpha1/restapi/ which will prevent developers from using OpenAPI specification to define REST APIs instead of building resource/method by resource/method.

Body was also left out for a later release, mainly because it requires more thought and is not part of CreateRestApi, but I do understand that many customers cannot onboard to API Gateway controller without support for this field. I'll prioritize it along with the aforementioned missing resources.

It'd not be good UX to require users to embed a large OpenAPI definition into a spec field, so we'll allow referencing a ConfigMap containing OpenAPI definitions. However, the maximum size of the OpenAPI definition file supported by PutRestApi is 6MB, which is much larger than a ConfigMap field can store, so we'll provide another field to supply an external source to download API definitions from. We might adopt CloudFormation's approach by providing a BodyS3Location field. Since updating the OpenAPI definition is a resource-intensive operation, we'll likely use the E-Tag for S3 objects to avoid fetching large objects during reconciliations.

Thanks for the feedback, @giedri.