这一切都是使用CDK完成的。
我通过基本路径映射(domain.addBasePathMapping()(创建了一个RESTneneneba API和与其关联的自定义域。效果很好。
由于某些要求，我还需要将另一个自定义域(我将其称为旧域(的特定路径重定向到此api。理论上，这应该很简单——只需创建一个从旧域到新API的基本路径映射。
这就是我尝试的方式：
const domain = DomainName.fromDomainNameAttributes(this, 'oldDomain', {
domainName: 'the old custom domain name',
domainNameAliasTarget: 'the "API Gateway domain name" value from the console for that domain',
domainNameAliasHostedZoneId: 'the "Hosted zone ID" value from the console for that domain',
});
new BasePathMapping(this, 'myMapping', {
domainName: domain,
restApi: this.api,
basePath: 'foo',
});
首先，我通过查找旧域创建了DomainName对象，然后创建了一个到我的新API的映射，其中包含一些路径。请注意，我不能对创建的域名调用addBasePathMapping()，因为该方法返回一个没有该方法的IDomainName。
当我运行这个时，它在旧的自定义域中创建了基本路径映射，指向我的新api，正确的stage，指定的路径。太棒了
只是没用。调用[old domain]/foo/bar(其中bar是新API中的资源路径(返回404。
奇怪的是，当我通过控制台手动创建映射时，它能完美地工作。
另一件奇怪的事情是，如果我通过CDK创建它，然后在控制台中编辑它，它就会开始工作。如果我删除它(手动或通过CDK(，然后通过CDK再次创建它，它就会继续工作。但这当然不是一个合适的解决方案。
我只能假设手动创建它会执行一些没有通过CDK构造完成的额外操作，但由于文档没有说明还需要做什么，我不知道该做什么。
解决方案是使用aws-cdk-lib/aws-apigatewayv2中的CfnApiMapping构造。事实上，这要容易得多，因为你不需要获得托管区域id等，只需向它传递一些现成的信息，它就会创建一个实际有效的基本路径映射：
new CfnApiMapping(this, 'myMapping', {
apiId: this.api.restApiId,
domainName: 'old custom domain'
stage: this.api.deploymentStage.stageName,
apiMappingKey: 'foo',
});
我应该提醒你，这伴随着奇怪的行为。
首先概述我的设置：
旧的api上有以下路径：[old api]/foo/bar。旧的自定义域直接映射到没有路径的旧api，因此旧的端点url是[old custom domain]/foo/bar。新的端点是[new custom domain]/bar。为了使旧URL映射到新api，我需要旧自定义域上foo的基本路径映射来指向新api，这样[old custom domain]/foo/bar将被定向到[new api]/bar。(请注意，foo上没有其他资源，也不会添加任何新资源，所以这很好。(
因此当前调用[old custom domain]/foo/bar会调用旧api上的/foo/bar路径。一旦部署了CfnApiMapping资源，调用相同的URL就会调用新api上的正确路径。
奇怪的行为1:如果我删除了基本路径映射，我希望它能回到原始的api。相反，我得到了一个403错误。如果我再次创建它，它将再次解析为新的API，再次删除它将再次出现403错误。
怪异行为2:如果我不删除它，而是更改路径值，使其不再映射"；foo"；，CCD_ 19路径再次与旧端点一起工作。然后我可以删除映射，一切都可以正常工作。
奇怪的行为3:我无法重新创建它，因为我记不清我采取了哪一系列步骤，但它发生了几次，我删除了基本路径映射，它继续工作，就好像映射仍然存在一样。控制台中没有可见的映射，我给了它足够的时间让更改生效，但它仍然有效。
所有这些都是用CDK完成的，而不是手动完成的。手动或通过常规的云形成来完成这项工作没有任何问题。