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

单数

方便 事物可以有不规则的复数名称。有时他们没有。 但是单数的名字总是存在的。

例如，CustomerAddress over CustomerAddresses

考虑这个相关的资源。

/order/12/orderdetail/12比/orders/12/orderdetails/4更具可读性和逻辑性。

数据库表

资源表示像数据库表这样的实体。 它应该有一个逻辑上的单数名称。 这是关于表名的答案。

类映射

类总是单数的。ORM工具生成的表与类名相同。随着越来越多的工具被使用，单数名称正成为一种标准。

阅读更多关于REST API开发者的困境

对于没有单一名称的事物

在裤子和太阳镜的例子中，它们似乎没有一个单一的对应。他们是众所周知的，他们似乎是单数的使用。就像一双鞋。考虑将类文件命名为Shoe或Shoes。在这里，这些名称的使用必须被视为一个单一的实体。你不会看到任何人买了一只鞋就把URL设为

/shoe/23

我们必须把鞋子看做一个单一的实体。

参考:Top 6 REST命名最佳实践

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

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

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

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

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

保持一致就好。

使用任何一个单数:

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

或复数:

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

我不喜欢看到url的{id}部分与子资源重叠，因为id理论上可以是任何东西，而且会有歧义。它混合了不同的概念(标识符和子资源名)。

类似的问题经常出现在枚举常量或文件夹结构中，其中混合了不同的概念(例如，当您有Tigers、Lions和Cheetahs文件夹时，在同一级别上还有一个名为Animals的文件夹——这没有意义，因为其中一个是另一个的子集)。

一般来说，我认为端点的最后一个命名部分如果一次处理单个实体，应该是单数，如果处理一组实体，则应该是复数。

处理单个用户的端点:

GET  /user             -> Not allowed, 400
GET  /user/{id}        -> Returns user with given id
POST /user             -> Creates a new user
PUT  /user/{id}        -> Updates user with given id
DELETE /user/{id}      -> Deletes user with given id

然后有一个单独的资源用于对用户进行查询，通常返回一个列表:

GET /users             -> Lists all users, optionally filtered by way of parameters
GET /users/new?since=x -> Gets all users that are new since a specific time
GET /users/top?max=x   -> Gets top X active users

下面是一些处理特定用户的子资源的例子:

GET /user/{id}/friends -> Returns a list of friends of given user

交个朋友(多对多链接):

PUT /user/{id}/friend/{id}     -> Befriends two users
DELETE /user/{id}/friend/{id}  -> Unfriends two users
GET /user/{id}/friend/{id}     -> Gets status of friendship between two users

永远不会有任何歧义，资源的复数或单数命名都是在暗示用户他们可以期待什么(列表或对象)。对id没有限制，理论上可以让id为new的用户不与(潜在的未来)子资源名重叠。