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使用者的角度来看，端点应该是可预测的

理想地...

1. GET /resources应该返回资源列表。
2. GET /resource应返回400级状态代码。
3. GET /resources/id/{resourceId}应该返回带有一个资源的集合。
4. GET /resource/id/{resourceId}应该返回一个资源对象。
5. POST /resources应该批量建立资源。
6. POST /resource应该建立一个资源。
7. PUT /resource应该更新资源对象。
8. PATCH /resource应该仅经过发布更改的属性来更新资源。
9. PATCH /resources应该批量更新资源，仅发布更改的属性。
10. DELETE /resources应该删除全部资源； 只是在开玩笑：400状态码
11. DELETE /resource/id/{resourceId}

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

综上所述，不管出于何种缘由，开发人员最经常使用的选择是使用复数形式。 这最终是我选择的路线，若是您查看诸如github和twitter类的流行api，这就是它们的做用。

决定的一些标准多是：

1. 个人时间限制是什么？
2. 我将容许个人消费者执行哪些操做？
3. 请求和结果有效载荷是什么样的？
4. 我是否但愿可以使用反射并解析代码中的URI？

所以，取决于您。 不管您作什么，都要保持一致。

---

#5楼

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

英文复数能够是很是任意的，它们没必要要地妨碍了代码。 遵照一个命名约定。 计算机语言应该是数学上的清晰度，而不是模仿天然语言。