使用AWS资源或Swagger API导入API网关？

Question

我将通过Cloudformation建立一个AWS API网关，并想知道什么是更好的解决方案：

我应该将AWS资源用于资源和方法，还是将我们拥有的知名OpenAPI（Swagger）文件导入API网关资源的更好方法？

从我的研究中，我发现使用招摇有一些局限性（https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-known-issues.html），但另一方面，它是创建API的标准。

因此，全面了解AWS Cloudformation可能会有一些缺点，我现在看不到。这就是为什么我要向处于相同情况的人寻求经验。感谢任何指导...

Merci A

Answer 1

我个人发现开发api网关资源的最佳方法是使用Serverless Framework，它超级易用，并且非常容易与其他AWS服务（即Lambda）集成。

此外，无服务器模式也只是cloudformation模板，因此它非常灵活。

Answer 2

如今，如果您不喜欢无服务器框架，则可以使用SAM（无服务器应用程序模型https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html）来编写模板。 其中的一些好处是，您可以编写更少的cloudformation代码，并且可以在本地调试/测试lambda / step函数。

Answer 3

以下是我对解决方案中的最佳实践的两分钱：

尽管开发产品，但是swagger或apiary是记录您的API并在实现它们之前快速模拟该API的出色工具。使用（例如）产品经理手中的模拟API和文档，就可以轻松地制定可靠的开发计划。但是诸如swagger之类的工具可以自动模拟API规范，如果您仅希望导入该规范以模拟API，则此导入功能是一个很好的使用工具，否则就不是。让我解释一下原因。

通过直接从swagger导入API并编排AWS资源会带来很多限制，主要的限制是您的开发过程不包括deleted或serverless之类的框架。这将迫使我们直接使用AWS控制台或AWS cli编写lambda函数，并使项目架构变得复杂。

在编写不带框架的lambda函数时，如果我们预先知道我们的函数将彼此正交并且不共享太多公共依赖关系，那么很好，这会起作用，但是对于具有（例如）数据库的任何项目，函数访问外部API，某些端点由授权者保护并拥有其他资源，使用框架绝对是更好的选择。创建图层和通用代码（例如数据库包装器类）更加容易。

使用任何框架时，最好从框架样板开始，使实现与文档相匹配。通过研究该框架的优点和局限性，我们可以确定它是否适合我们的体系结构。

此外，IMO，这种方法并未得到广泛使用，随着项目变得更加复杂，在以后寻求帮助可能会很困难。

希望这会有所帮助。