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

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

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

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

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

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

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

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) 

复数

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

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

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

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

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

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

对于命名惯例，通常可以安全地说“只选择一个并坚持使用它”，这是有道理的。

然而，在不得不向许多人解释REST之后，将端点表示为文件系统上的路径是最具表现力的方法。 它是无状态的(文件存在或不存在)，分层的，简单的，熟悉的-您已经知道如何访问静态文件，无论是本地还是通过http。

在这种情况下，语言规则只能让你达到以下效果:

一个目录可以包含多个文件和/或子目录，因此它的名称应该是复数形式。

但我喜欢妳 不过，另一方面，这是您的目录，如果您愿意，您可以将其命名为“一个资源或多个资源”。这不是真正重要的事情。

重要的是，如果您将一个名为“123”的文件放在名为“resourceS”的目录下(结果是/resourceS/123)，那么您就不能期望通过/resource/123访问它。

不要试图让它变得比原来更聪明——根据你当前访问的资源数量从复数变成单数对某些人来说可能是美观的，但这并不是有效的，在一个等级系统中也没有意义。

注意:技术上，你可以创建“符号链接”，这样/resources/123也可以通过/resource/123访问，但前者仍然必须存在!