我不喜欢看到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的用户不与(潜在的未来)子资源名重叠。

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

复数

简单-所有url都以相同的前缀开头 逻辑——订单/获取订单的索引列表。 标准——被绝大多数公共和私有api广泛采用的标准。

例如:

GET /resources -返回资源项的列表

POST /resources -创建一个或多个资源项

PUT /resources—更新一个或多个资源项

PATCH /resources—部分更新一个或多个资源项

DELETE /resources -删除所有资源项

对于单个资源项:

GET /resources/:id -根据:id参数返回一个特定的资源项

POST /resources/:id—用指定的id创建一个资源项(需要验证)

PUT /resources/:id -更新一个特定的资源项

PATCH /resources/:id—部分更新特定的资源项

DELETE /resources/:id -删除指定的资源项

对于单数的提倡者，可以这样想:你会向某人要一份订单，并期待一件事，还是一份清单?那么，当您键入/订单时，为什么期望服务返回一列东西呢?

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

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

我知道大多数人都在犹豫是用复数还是单数。这里没有解决的问题是，客户需要知道您使用的是哪一个，而且他们总是有可能犯错误。这就是我的建议的来源。

两者都怎么样?我的意思是，在整个API中使用单数形式，然后创建路由，将复数形式的请求转发到单数形式。例如:

GET  /resources     =     GET  /resource
GET  /resources/1   =     GET  /resource/1
POST /resources/1   =     POST /resource/1
...

你懂的。没有人是错的，最小的努力，客户总是会得到正确的。

单数

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

例如，CustomerAddress over CustomerAddresses

考虑这个相关的资源。

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

数据库表

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

类映射

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

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

对于没有单一名称的事物

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

/shoe/23

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

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