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

Question

我正在使用无服务器框架构建API。终端节点在 Amazon API 网关上定义，其中每个签名都映射到单个 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相比，大声说出来时读起来更好，听起来更自然(例如userCreate(。但是我发现在开始时更容易有上下文部分(例如公司或应用程序;如果需要，但如果可能的话最好避免(，因为它有助于工具更好地组织方法(例如contextCommandObjectAbcCoCustomerServiceAppCreateUser(。

简而言之，让它变得简单，避免使用任何隐含明显的东西，但如果需要，允许区分命名空间中的不同应用程序/系统/实体。

Answer 2

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

但是，如果这个 lambda 调用其他 lambda 来编排所涉及的单独工作单元，那么我们也可以以不同的方式命名它。

备选方案

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

可以使用的饼干切割机

• 如果它只执行一种类型的活动，则名称应是一个动词，用于限定createUserAPILambda或createUser
• 如果它执行多个活动，我们可能会有一个名词来执行操作，例如userDatabaseLambda.
• 保持命名足够简短，但完全符合任何可能变化的跨领域方面，例如createUser最初已经足够好了，但当我们拆分它以提高可重用性时，它变得createUserAPILambda。(微与纳米(