用于REST访问的AWS Lambdas的命名约定

Question

我正在用Serverless框架构建一个API。端点在Amazon网关上定义，其中每个签名都映射到单个Lambda。

这里的羔羊有什么好的命名惯例？例如，POST /user的候选人可以是：

• userPost
• createUser

Answer 1

命名总是很难的。

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

此外，还需要考虑lambda函数的命名空间范围--例如，如果您的函数的所有都与企业ABC的应用程序XYZ中的用户相关，那么create就足够了。

但是，如果您对两个企业都有lambda函数，而且每个企业都有多个具有用户管理的应用程序，并且可能需要针对不同的事情使用不同的create方法，那么您可能需要类似于AbcApplicationxyzCreateUser的东西。

另一条评论--在英语中，commandObject (例如createUser)读起来更好，与objectCommand (例如userCreate)相比，大声说起来更自然。但是，我发现在一开始就让上下文部分(如公司或应用程序；如果需要，但最好避免)更容易，因为它有助于更好地组织方法的工具(contextCommandObject，例如AbcCoCustomerServiceAppCreateUser)。

简而言之，让它变得简单，避免使用任何隐式显而易见的东西，但允许在需要时区分名称空间中的不同应用程序/系统/实体。

Answer 2

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

然而，如果这个lambda正在调用其他lambda来编排所涉及的独立的工作单元，那么我们也可以将它命名为不同的。

备用场景

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

可用于的饼干切割器

• 如果它只进行一种类型的活动，那么名称应该是一个动词，可以限定为createUserAPILambda或createUser。
• 如果它做了多个活动，我们可能有一个名词来执行这些操作，例如userDatabaseLambda。
• 命名要足够短，但完全符合任何可能不同的横切方面的条件，例如，createUser最初已经足够好了，但是当我们为了提高可重用性而将它分开时，它就变成了createUserAPILambda。