为了简单和一致性，我更喜欢使用单数形式。

例如，考虑以下url:

/客户/ 1

我将把客户视为客户集合，但是为了简单起见，集合部分被删除了。

另一个例子:

/设备/ 1

在这种情况下，equipment不是正确的复数形式。因此，为了简单起见，将其视为设备集合和删除集合，使其与客户案例一致。

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

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

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

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

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

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

对我来说，最好有一个模式，你可以直接映射到代码(容易自动化)，主要是因为代码是什么将在两端。

GET  /orders          <---> orders 
POST /orders          <---> orders.push(data)
GET  /orders/1        <---> orders[1]
PUT  /orders/1        <---> orders[1] = data
GET  /orders/1/lines  <---> orders[1].lines
POST /orders/1/lines  <---> orders[1].lines.push(data) 

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

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

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

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