REST URI约定-创建资源时的单数或复数名称

我是REST的新手，我注意到在某些RESTful服务中，它们使用不同的资源URI进行更新/获取/删除和创建。如

创建-使用POST方法，使用/资源 （观察复数），使用/资源有些地方（单数）
更新-使用/ resource / 123和PUT方法
获取-将/ resource / 123与GET方法一起使用

我对此URI命名约定有点困惑。我们应该使用复数还是单数来创建资源？决定的标准是什么？

#1楼

尽管最普遍的实践是使用复数的RESTful api，例如/api/resources/123 ，但在一种特殊情况下，我发现使用单数名称比复数名称更合适/更具表达性。一对一的关系就是这种情况。特别是如果目标项目是值对象（在域驱动设计范式中）。

让我们假设每个资源都有一对一的accessLog ，可以将其建模为值对象，即不是实体，因此没有ID。它可以表示为/api/resources/123/accessLog 。常用动词（POST，PUT，DELETE和GET）会适当地表达意图，并且也表明这种关系确实是一对一的。

#2楼

为什么不遵循通常接受单数形式的数据库表名称的流行趋势？到那里，做完了-让我们重复使用。

表命名难题：单数与复数名称

#3楼

对我来说，最好有一个可以直接映射到代码的模式（易于自动化），这主要是因为代码将是两端。

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)

#4楼

从API使用者的角度来看，端点应该是可预测的

理想地...

GET /resources应该返回资源列表。
GET /resource应返回400级状态代码。
GET /resources/id/{resourceId}应该返回带有一个资源的集合。
GET /resource/id/{resourceId}应该返回一个资源对象。
POST /resources应该批量创建资源。
POST /resource应该创建一个资源。
PUT /resource应该更新资源对象。
PATCH /resource应该仅通过发布更改的属性来更新资源。
PATCH /resources应该批量更新资源，仅发布更改的属性。
DELETE /resources应该删除所有资源；只是在开玩笑：400状态码
DELETE /resource/id/{resourceId}

这种方法最灵活，功能最丰富，但开发时间也最长。因此，如果您很着急（在软件开发中通常如此），只需命名端点resource或复数形式的resources 。我更喜欢单数形式，因为它可以让您选择以编程方式进行内省和评估，因为并非所有复数形式都以“ s”结尾。

综上所述，无论出于何种原因，开发人员最常用的选择是使用复数形式。这最终是我选择的路线，如果您查看诸如github和twitter类的流行api，这就是它们的作用。

决定的一些标准可能是：

我的时间限制是什么？
我将允许我的消费者执行哪些操作？
请求和结果有效载荷是什么样的？
我是否希望能够使用反射并解析代码中的URI？

因此，取决于您。无论您做什么，都要保持一致。

#5楼

我的两分钱：花费时间从复数变为单数或反之亦然的方法是浪费CPU周期。我可能是高中生，但是在我的时代，事物被称为相同。我如何查找有关人的方法？没有规律的表达不会覆盖人和人，而不会产生不良副作用。

英文复数可以是非常任意的，它们不必要地妨碍了代码。遵守一个命名约定。计算机语言应该是数学上的清晰度，而不是模仿自然语言。

来源：oschina

链接：https://my.oschina.net/u/3797416/blog/3159852

标签

复数

rest