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

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

GET /resources?Id=123

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

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

GET /resource?Id=123

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

为什么不遵循数据库表名的流行趋势，通常采用单数形式?有过这样的经历，让我们重新使用。

表命名困境:单数和复数名称

尽管最流行的做法是使用复数的RESTful api，例如/api/resources/123，但有一个特殊的情况，我发现使用单数名称比使用复数名称更合适/更具表现力。这是一对一关系的例子。特别是如果目标项是一个值对象(在领域驱动设计范例中)。

让我们假设每个资源都有一个一对一的accessLog，它可以被建模为一个值对象，即不是实体，因此没有ID。它可以表示为/api/resources/123/accessLog。通常的动词(POST、PUT、DELETE、GET)可以恰当地表达意图，以及关系确实是一对一的事实。

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

使用/resources的前提是它表示“所有”资源。如果执行GET /resources，则可能返回整个集合。通过发布到/resources，您将添加到集合中。

但是，单个资源在/resource上可用。如果执行GET /resource请求，则可能会出错，因为这个请求没有任何意义，而/resource/123则完全有意义。

使用/resource而不是/resources类似于使用文件系统和文件集合，/resource是包含单独的123,456个文件的“目录”。

没有对错之分，你喜欢什么就去做什么。

在所有方法中使用复数至少在一个方面更实用: 如果你正在使用Postman(或类似的工具)开发和测试资源API，当从GET切换到PUT再切换到POST时，你不需要编辑URI。