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

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

这方便地从左到右匹配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对单个请求只能有一个响应。路径总是指一个单数的东西。

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

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

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

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

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

我也不认为这样做有什么意义，我认为这不是最好的URI设计。作为RESTful服务的用户，无论我访问的是列表还是列表中的特定资源，我都希望列表资源具有相同的名称。无论使用列表资源还是特定资源，都应该使用相同的标识符。

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

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

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

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