REST URL命名约定/ items/{id} vs/items？id = {id}

Question

我理解在MVC模式和REST服务中使用URI很常见,/items/{id}但在URI中使用查询参数有什么坏处？

GET /items/{id} VS GET /items?id={id}

此外,假设一个实体有'referenceId'字段指向一些相关(比如父)实体,我需要创建REST服务来获取父实体的所有项目,哪种方式更好:

GET(POST) /items/parent/{parentId} 

要么

GET(POST) /items?parent={parentId}

将会感谢有助于解决构建REST服务URL的主观问题的见解.

Answer 1

我会使用以下方案.

/items/id

这唯一地解决了具有id的项目的资源id.我们没有使用参数作为唯一地寻址此资源的参数(与其他选项的情况一样).就像miguelcobain所说的那样.

/parent/id/items

这id是一个唯一地寻址父资源的ID,以及我们收集/检索它引用的项的资源.根据你在问题中所说的,似乎父引用了多个项目,比如容器或集合.

我使用的惯例是缩小从左到右的范围.因此,如果物品可以是active或inactive.正是如此的项目有一个属性或属性是active或inactive.缩小这个我得到以下方案:

/items/active
/parent/id/active

Answer 2

对于你的第一个问题：

/items/{id}应检索具有指定 ID 的单个资源，或者404如果该资源不存在。

/items/?id={id}应该检索一个数组（即使数组中只有一个），因为您正在查询集合。

对于你的第二个问题：

我同意@miguelcobain 的评估 - 如果该项目是特定资源/实体，只需使用正确的资源路径来检索它。

为了使消费者更容易做到这一点，请创建一个带有 uri 的链接标头和rel="parent"/或在子资源中包含 uri。有关链接标头的示例，请参阅 GitHub 的分页 api。