如何:

/resource/(不是/resource)

/resource/意味着它是一个包含“resource”的文件夹，它是一个“resource”文件夹。

而且我认为数据库表的命名惯例是相同的，例如，一个叫“user”的表就是一个“user”表，它包含了一个叫“user”的东西。

使用/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 -删除指定的资源项

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

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

保持一致就好。

使用任何一个单数:

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

或复数:

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

单数

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

例如，CustomerAddress over CustomerAddresses

考虑这个相关的资源。

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

数据库表

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

类映射

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

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

对于没有单一名称的事物

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

/shoe/23

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

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