I decided to port my many-services API to use the new shared API functionality merged in 1.26:
My use case is common, I have a REST API and I have deployed each resource as its own serverless service, and thus I end up with a bloated amount of APIG APIs… so this new orchestration scheme is a must, it also implies many other benefits in addition to mental sanity.
My design is to use a “master” API, in which I declare common resources sich as
BasePathMapping for my custom domains. Then I reference this master API and its
RootResourceId as a shared APIG for my other services such as:
apiGateway: restApiId: xxxxxxxx restApiRootResourceId: yyyyyyyy
Nice!, with that I end up with a single API, but I have found complications… My full REST API has the following structure:
/ /resource1 /resource2 /resourceN
Each resource is contained within its own service so, so my master API does not have any defined methods!!, it has never happened to me before having defined an “empty” APIG… but it seems that AWS does not allow to create a deploy for this API. Just try it in the console or in CloudFormation and you will hit an error “The API has not defined any methods”
Define a dummy endpoint in the master API (such as
GET /) and you would be able to define your deployment in CloudFormation (or allow serverless to create it for you, though you might have to create a dummy lambda function as well)
Has this happened to me because I am trying to implement some kind of anti-pattern? or just happened I have hit this APIG limitation given that my deployment strategy is biased towards using serverless?
Thanks for the feedback in advance!!