RESTURI约定-创建资源时的单数或复数名称怎么弄?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (10)
  • 关注 (0)
  • 查看 (211)

我对REST很陌生,我注意到在一些RESTful服务中,它们使用不同的资源URI来更新/获取/删除和创建。如

  • 创建-使用/resources用POST方法(观察复数)在某些地方使用/resources(单数)
  • 更新-使用/resources/123用放法
  • 利用/resources/123用GET方法

我对这个URI命名约定有点困惑。我们应该使用什么复数或单数来创建资源?

提问于
用户回答回答于

使用前提/resources它代表的是“所有”资源。如果你做了GET /resources,你可能会返回整个集合。通过投寄到/resources,你将添加到集合中。

但是,单个资源可在/资源处使用。如果你做了GET /resource,你可能会出错,因为这个请求没有任何意义,而/resource/123很有道理。

使用/resource而不是/resources类似于如果你正在处理文件系统和文件集合,则你将如何进行此操作,并且,如果你使用的是文件系统和文件的集合,则/resource是个人的“目录”。123,,,456里面的文件。

无论是对还是错,都要随心所欲。

用户回答回答于

有了命名约定,通常可以说“选一个就行”,这是有道理的。

但是,在不得不向许多人解释REST之后,将端点表示为文件系统上的路径是最有表现力的方式。

它是无状态的(文件要么存在,要么不存在)、分层、简单和熟悉--您已经知道如何访问静态文件,无论是本地文件还是通过http。

在这种情况下,语言规则只能让你达到以下目的:

一个目录可以包含多个文件和/或子目录,因此它的名称。以复数形式出现。

我喜欢这样。

虽然,另一方面-这是您的目录,您可以命名它为“资源-或多资源”,如果这是你想要的。这并不是最重要的。

重要的是,如果您将一个名为“123”的文件放在一个名为“resources”的目录下(结果是/resourceS/123),您就不能期望它可以通过/resource/123...

不要试图让它变得更聪明--根据当前访问的资源数量从复数变为单路,对某些人来说可能是美观的,但它并不有效,也没有任何意义。分层次系统。

注意:从技术上讲,你可以创建“符号链接”,以便/resources/123也可以通过/resource/123___,但前者仍然存在!

用户回答回答于

把时间从复数变为单数或反之亦然的方法是浪费CPU周期。我也许是个老派,但在我这个时代,事情也是一样的。如何查找有关人的方法?没有规律的表达将涵盖人和人,没有不良的副作用。

英语复数可能非常武断,它们对代码进行了不必要的限制。坚持一个命名惯例。计算机语言应该是数学清晰,而不是模仿自然语言。

用户回答回答于

从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’结尾。

尽管如此,出于任何原因,最常用的实践开发人员选择的是使用复数形式。这是我最终选择的路线,如果您看一下流行的API,比如githubtwitter他们就是这么做的。

决定的一些标准可以是:

  1. 我的时间限制是什么?
  2. 我将允许我的消费者做什么操作?
  3. 请求和结果有效负载是什么样子的?
  4. 我希望能够在代码中使用反射并解析URI吗?

所以这取决于你。不管你做什么都是一致的。

用户回答回答于

为什么不遵循数据库表名的流行趋势,在这种情况下,单数形式被普遍接受?

用户回答回答于

单数

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

例如CustomerAddress胜过CustomerAddress

请考虑这一相关资源。

/order/12/orderdetail/12/orders/12/orderdetails/4...

数据库表

资源表示类似于数据库表的实体。它应该有一个合乎逻辑的单数名称。

类映射

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

用户回答回答于

RESTURI中资源名称的多元化是广泛采用的标准,其次是绝大多数公共和私有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-删除特定资源项

用户回答回答于

而最普遍的做法是RESTfulAPI,其中使用复数。/api/resources/123,有一个特殊情况,我发现使用单数名称比复数名称更合适/更有表现力。这是一对一关系的情况。具体而言,如果目标项是一个值对象。

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

用户回答回答于

我也不认为这样做有什么意义,我认为这不是最好的URI设计。作为RESTful服务的用户,无论我是访问列表还是访问列表中的特定资源,我都希望列表资源具有相同的名称。无论你想要使用列表资源还是特定资源,都应该使用相同的标识符。

用户回答回答于

对我来说,最好是有一个模式,你可以直接映射到代码(易于自动化),主要是因为代码是两端的东西。

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) 

所属标签

可能回答问题的人

  • 天使的炫翼

    16 粉丝531 提问35 回答
  • 富有想象力的人

    2 粉丝0 提问26 回答
  • 旺仔小小鹿

    社区 · 运营 (已认证)

    48 粉丝0 提问26 回答
  • 发条丶魔灵1

    6 粉丝525 提问25 回答

扫码关注云+社区

领取腾讯云代金券