我的观点是:那些把时间从复数变成单数或者反过来的方法是在浪费CPU周期。我可能是个老派，但在我那个时代，类似的东西都是一样的。如何查找有关人员的方法?任何正则表达式都不能同时覆盖person和people而没有不良的副作用。

英语复数可以是非常随意的，它们不必要地妨碍代码。坚持一个命名约定。计算机语言应该是关于数学的清晰性，而不是关于模仿自然语言。

我的观点是:那些把时间从复数变成单数或者反过来的方法是在浪费CPU周期。我可能是个老派，但在我那个时代，类似的东西都是一样的。如何查找有关人员的方法?任何正则表达式都不能同时覆盖person和people而没有不良的副作用。

英语复数可以是非常随意的，它们不必要地妨碍代码。坚持一个命名约定。计算机语言应该是关于数学的清晰性，而不是关于模仿自然语言。

对我来说，复数操作集合，而单数操作集合中的项。

集合允许使用GET / POST / DELETE方法

项允许GET / PUT / DELETE方法

例如

POST on /students将在学校增加一名新学生。

DELETE on /students将删除学校中的所有学生。

DELETE /student/123将从学校删除学生123。

这可能感觉不重要，但一些工程师有时会忘记id。如果路由总是复数并执行DELETE，可能会意外擦除数据。而在奇异点上缺少id则会返回404路由。

为了进一步扩展示例，如果API应该公开多所学校，那么如下所示

DELETE on /school/abc/students将删除学校abc中的所有学生。

选择正确的词语有时本身就是一个挑战，但我喜欢保持语汇的多样性。例如cart_items或cart/items感觉正确。相反，删除购物车，删除的是购物车对象本身，而不是购物车中的物品;)。

对我来说，最好有一个模式，你可以直接映射到代码(容易自动化)，主要是因为代码是什么将在两端。

GET  /orders          <---> orders 
POST /orders          <---> orders.push(data)
GET  /orders/1        <---> orders[1]
PUT  /orders/1        <---> orders[1] = data
GET  /orders/1/lines  <---> orders[1].lines
POST /orders/1/lines  <---> orders[1].lines.push(data) 

路由中的id应该被看作是列表的索引，命名也应该相应地进行。

numbers = [1, 2, 3]

numbers            GET /numbers
numbers[1]         GET /numbers/1
numbers.push(4)    POST /numbers
numbers[1] = 23    PUT /numbers/1

但是有些资源在它们的路由中不使用id，因为要么只有一个id，要么一个用户永远不能访问多个id，所以这些不是列表:

GET /dashboard
DELETE /session
POST /session
GET /users/{:id}/profile
PUT /users/{:id}/profile

如何:

/resource/(不是/resource)

/resource/意味着它是一个包含“resource”的文件夹，它是一个“resource”文件夹。

而且我认为数据库表的命名惯例是相同的，例如，一个叫“user”的表就是一个“user”表，它包含了一个叫“user”的东西。