路由中的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

在这个问题上有很好的讨论点。在我的经验中，命名约定或者更确切地说，没有建立本地标准是许多长夜待命、头痛、危险的重构、可疑的部署、代码审查辩论等等的根本原因。特别是当它决定事情需要改变，因为一开始就没有充分考虑到。

一个实际问题跟踪了关于这个问题的讨论:

https://github.com/kubernetes/kubernetes/issues/18622

在这个问题上看到分歧是很有趣的。

我的观点是，当你考虑用户、帖子、订单、文档等常见实体时，你应该始终将它们视为实际实体，因为这是数据模型的基础。这里不应该混淆语法和模型实体，这将导致其他方面的混淆。然而，一切都是黑白的吗?确实很少这样。环境真的很重要。

当你想获取系统中用户的集合时，例如:

GET /user ->用户实体集合

GET /user/1 ->实体资源user:1 .单击“确定”

说我想要一个实体user的集合和说我想要users的集合都是有效的。

GET /users ->实体用户集合

GET /users/1 ->实体用户资源:1 .单击“确定”

从这里你可以说，从用户集合中，给我user /1。

但如果你分解用户的集合……它是一个实体的集合，其中每个实体都是一个User实体。

您不会说实体是用户，因为单个数据库表通常是用户的单个记录。但是，我们这里讨论的是基于rest的服务，而不是数据库ERM。

但这只适用于名词区分清楚的用户，而且很容易掌握。然而，当一个系统中有多种相互冲突的方法时，事情就会变得非常复杂。

事实上，这两种方法在大多数情况下都是有意义的，除了少数情况下英语就像意大利面条一样。它似乎是一种迫使我们做出许多决定的语言!

简单的事实是，无论你决定什么，你的意图要一致且合乎逻辑。

在我看来，在这里和那里混合是一个糟糕的方法!这会悄悄地引入一些可以完全避免的语义歧义。

看似单一的偏好:

https://www.haproxy.com/blog/using-haproxy-as-an-api-gateway-part-1/

这里也有类似的讨论:

https://softwareengineering.stackexchange.com/questions/245202/what-is-the-argument-for-singular-nouns-in-restful-api-resource-naming

这里最重要的常数是，这似乎确实取决于某种程度的团队/公司文化偏好，根据更大的公司指南中的细节，这两种方式都有许多优点和缺点。谷歌不一定是正确的，因为它是谷歌!这适用于任何指导方针。

不要把你的头埋在沙子里，不要把你的整个理解系统松散地建立在轶事例子和观点上。

你有必要为每件事建立坚实的推理吗?如果它适合你、你的团队和你的客户，并且对新手和经验丰富的开发者(如果你是在团队环境中)有意义，那就很好。

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

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

保持一致就好。

使用任何一个单数:

POST /resource
PUT  /resource/123
GET  /resource/123

或复数:

POST /resources
PUT  /resources/123
GET  /resources/123

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

集合允许使用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感觉正确。相反，删除购物车，删除的是购物车对象本身，而不是购物车中的物品;)。

使用单数，并利用英语惯例，如:“商业目录”。

很多东西都是这样读的:“书柜”、“狗窝”、“美术馆”、“电影节”、“汽车场”等等。

这方便地从左到右匹配url路径。左边的项目类型。在右侧设置类型。

GET /users真的获取过一组用户吗?不是很经常。它获取一组存根，其中包含一个密钥，也许还有一个用户名。所以它不是/users。它是一个用户索引，或者你可以称之为“用户索引”。为什么不这么叫呢?它是/user/index。由于我们已经命名了set类型，我们可以有多个类型来显示用户的不同投影，而无需求助于查询参数，例如user/phone-list或/user/mail -list。

那么用户300呢?仍然是/user/300。

GET /user/index
GET /user/{id}

POST /user
PUT /user/{id}

DELETE /user/{id}

最后，HTTP对单个请求只能有一个响应。路径总是指一个单数的东西。