我即将通过Cloudformation建立一个AWS API网关，并想知道什么是更好的解决方案：
我应该使用AWS资源进行资源和方法，还是将我们熟悉的OpenAPI（Swagger）文件导入API网关资源的更好方法？
从我的研究中我发现使用swagger有一些限制（https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-known-issues.html），但另一方面它是创建API的标准。
因此，全面了解AWS Cloudformation可能会有一些我现在看不到的缺点。这就是为什么我要求处于相同情况的人的经历。感谢任何指导......
谢谢A.
我个人认为开发api网关资源的最佳方法是使用Serverless Framework，它非常易于使用，并且可以非常轻松地与其他AWS服务集成，即Lambda。
无罩服务器只是cloudformation模板，所以它非常灵活。
如果您不喜欢无服务器框架，现在可以使用SAM（无服务器应用程序模型https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html）编写模板。一些好处是您编写了较少的云形式代码，您可以在本地调试/测试您的lambda / step函数。
以下是您解决方案中最佳实践的两分钱：
在开发产品时，swagger或apiary是记录API并在实现API之前快速模拟API的绝佳工具。通过模拟API和（例如）产品经理手中的文档，可以很容易地开始制定可靠的开发计划。但是像swagger这样的工具可以自动模拟API规范，如果你只想导入这个规范来模拟API，那么这个导入功能是一个很好的工具，否则它不是。让我解释一下原因。
通过导入API并直接从swagger编排AWS资源，您会带来许多限制，主要的一个是您的开发过程不包括serverless或zappa等框架。这将迫使我们使用AWS控制台或AWS cli直接编写lambda函数，并使项目架构变得复杂。
在没有框架的情况下编写lambda函数时，如果我们事先知道我们的函数将彼此正交并且不共享很多公共依赖项，那么很好，这可行，但是对于任何具有（比如）数据库的项目，函数访问外部API，一些端点由授权者保护并拥有其他资源，使用框架绝对是更好的选择。创建图层和公共代码更容易，例如数据库包装类。
使用任何框架时，最好从框架样板开始，并使实现与文档匹配。通过研究该框架的优点和局限性，我们可以决定它是否适合我们的架构。
此外，IMO，这种方法并没有被广泛使用，随着项目变得更加复杂，以后寻求帮助可能会很艰难。
希望这可以帮助。