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

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

以下是Roy Fielding关于“基于网络的软件架构的架构风格和设计”的论文，这句话你可能会感兴趣:

资源是概念上的映射 到一组实体，而不是与中任何特定点的映射对应的实体 时间。

作为一个资源，映射到一组实体，对我来说，使用/product/作为访问一组产品的资源，而不是/products/本身，似乎不符合逻辑。如果需要特定的产品，则访问/products/1/。

作为进一步的参考，这个来源有一些关于资源命名约定的单词和例子:

https://restfulapi.net/resource-naming/

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

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

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

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

复数

简单-所有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 -删除指定的资源项

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

从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 ?

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

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

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

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

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