我更喜欢同时使用复数(/resources)和单数(/resource/{id})，因为我认为它更清楚地区分了处理资源集合和处理单个资源之间的逻辑。

作为一个重要的副作用，它还可以帮助防止某些人错误地使用API。例如，考虑这样一种情况，用户错误地试图通过将Id指定为如下参数来获取资源:

GET /resources?Id=123

在本例中，我们使用复数形式，服务器很可能会忽略Id参数并返回所有资源的列表。如果用户不小心，他会认为调用成功，并使用列表中的第一个资源。

另一方面，当使用单数形式时:

GET /resource?Id=123

服务器很可能会返回一个错误，因为Id没有以正确的方式指定，并且用户将不得不意识到某些事情是错误的。

我更喜欢同时使用复数(/resources)和单数(/resource/{id})，因为我认为它更清楚地区分了处理资源集合和处理单个资源之间的逻辑。

作为一个重要的副作用，它还可以帮助防止某些人错误地使用API。例如，考虑这样一种情况，用户错误地试图通过将Id指定为如下参数来获取资源:

GET /resources?Id=123

在本例中，我们使用复数形式，服务器很可能会忽略Id参数并返回所有资源的列表。如果用户不小心，他会认为调用成功，并使用列表中的第一个资源。

另一方面，当使用单数形式时:

GET /resource?Id=123

服务器很可能会返回一个错误，因为Id没有以正确的方式指定，并且用户将不得不意识到某些事情是错误的。

对于命名惯例，通常可以安全地说“只选择一个并坚持使用它”，这是有道理的。

然而，在不得不向许多人解释REST之后，将端点表示为文件系统上的路径是最具表现力的方法。 它是无状态的(文件存在或不存在)，分层的，简单的，熟悉的-您已经知道如何访问静态文件，无论是本地还是通过http。

在这种情况下，语言规则只能让你达到以下效果:

一个目录可以包含多个文件和/或子目录，因此它的名称应该是复数形式。

但我喜欢妳 不过，另一方面，这是您的目录，如果您愿意，您可以将其命名为“一个资源或多个资源”。这不是真正重要的事情。

重要的是，如果您将一个名为“123”的文件放在名为“resourceS”的目录下(结果是/resourceS/123)，那么您就不能期望通过/resource/123访问它。

不要试图让它变得比原来更聪明——根据你当前访问的资源数量从复数变成单数对某些人来说可能是美观的，但这并不是有效的，在一个等级系统中也没有意义。

注意:技术上，你可以创建“符号链接”，这样/resources/123也可以通过/resource/123访问，但前者仍然必须存在!

请参阅谷歌的API设计指南:资源名称以了解另一种命名资源的方法。

该指南要求集合以复数形式命名。

|--------------------------+---------------+-------------------+---------------+--------------|
| API Service Name         | Collection ID | Resource ID       | Collection ID | Resource ID  |
|--------------------------+---------------+-------------------+---------------+--------------|
| //mail.googleapis.com    | /users        | /name@example.com | /settings     | /customFrom  |
| //storage.googleapis.com | /buckets      | /bucket-id        | /objects      | /object-id   |
|--------------------------+---------------+-------------------+---------------+--------------|

如果你正在思考这个问题，这本书值得一读。

从API使用者的角度来看，端点应该是可预测的

在理想的情况下……

GET /resources should return a list of resources. GET /resource should return a 400 level status code. GET /resources/id/{resourceId} should return a collection with one resource. GET /resource/id/{resourceId} should return a resource object. POST /resources should batch create resources. POST /resource should create a resource. PUT /resource should update a resource object. PATCH /resource should update a resource by posting only the changed attributes. PATCH /resources should batch update resources posting only the changed attributes. DELETE /resources should delete all resources; just kidding: 400 status code DELETE /resource/id/{resourceId}

这种方法最灵活，功能最丰富，但开发起来也最耗时。因此，如果您很着急(软件开发总是这样)，只需命名您的端点资源或复数形式的资源。我更喜欢单数形式，因为它让你可以选择内省和编程计算，因为不是所有的复数形式都以's'结尾。

说了这么多，不管出于什么原因，最常用的实践开发人员选择使用复数形式。这是我最终选择的路线，如果你看看流行的api，如github和twitter，这就是他们所做的。

决定的一些标准可以是:

我的时间限制是什么? 我将允许我的消费者做哪些操作? 请求和结果有效负载是什么样子的? 我是否希望能够在代码中使用反射并解析URI ?

所以这取决于你。无论你做什么都要坚持。

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