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