适用于REST API访问的AWS Lambda的命名约定

Question

我正在使用无服务器框架构建API。端点在Amazon API Gateway上定义，每个签名都映射到一个单独的Lambda。

这里的Lambda的良好命名约定是什么？例如，POST /user的候选人可能是：

• userPost
• createUser

Answer 1

命名总是很困难。

对于一般命名-这是一个很好的答案：https://softwareengineering.stackexchange.com/a/130104

此外，lambda函数的名称空间范围是一个考虑因素-例如如果您的所有所有功能都与企业ABC的应用程序XYZ中的用户有关，则create就足够了。

但是，如果您同时具有企业ABC和DEF的lambda功能，并且每个企业都有多个具有用户管理功能的应用程序，并且可能需要针对不同事物的不同create方法，那么您可能需要类似于AbcApplicationxyzCreateUser。

另一条评论-用英语commandObject（例如createUser）与objectCommand（例如{{ 1}}）。但是我发现开始时更容易使用上下文部分（例如 company 或 application ；如果需要，最好避免使用），因为这有助于工具组织方法更好（userCreate，例如contextCommandObject）。

简而言之，请简化操作，避免使用任何明显不明显的内容，但如果需要，可以区分名称空间中的不同应用程序/系统/实体。

Answer 2

POST /User的HTTP约定更适用于描述API的网关层，执行此操作的后端功能是创建用户。公开的API是许多可能触发此功能的事件源之一。例如，将来可以通过任何其他来源通过SNS事件调用该函数。因此，根据功能的确切功能（业务逻辑）来命名功能将是适当的。这里createUser听起来不错。

但是，如果此Lambda调用其他Lambda来编排涉及的单独工作单元，那么我们也可以使用不同的名称。

替代方案

如果我们将API设计为由多个lambda函数组成。例如，如果我们需要createUser流程，那么最终也会做其他后端操作（特别是在大型企业中）。我们可能有一个POST /用户API网关调用createUserAPILambda，调用userDatabaseLambda，sendWelcomeEmailLambda和assignProjectLambda。下游功能可以单独重用，并且可能不是原始API本身的一部分。

可以使用的Cookie切割器

• 如果仅执行一种活动，则名称应为限定动词的动词，例如createUserAPILambda或createUser
• 如果它进行多项活动，我们可能会有一个名词来执行操作，例如userDatabaseLambda。
• 将名称保留足够短的时间，但要完全符合可能变化的任何交叉方面，例如createUser最初已经足够好，但是当我们将其拆分以提高可重用性时，它就变成了createUserAPILambda。（Micro与Nano）