9

我知道在 MVC 模式和 REST 服务中，使用 URI 是很常见的，/items/{id}但是在 URI 中使用查询参数有什么不好的呢？

GET /items/{id}对比GET /items?id={id}

此外，假设一个实体具有指向某个相关（例如父）实体的“referenceId”字段，我需要创建 REST 服务来获取父实体的所有项目，哪种方式更好：

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

或者

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

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

4

4 回答 4

6

我会使用以下方案。

/items/id

这唯一地解决了具有 id 的项目资源id。我们没有使用参数作为参数来唯一地寻址该资源（与其他选项一样）。正如 miguelcobain 建议的那样。

/parent/id/items

这id是一个 id，用于唯一寻址父资源以及我们从那些我们收集/检索它引用的项目的资源。从您在问题中所说的来看，似乎 parent 引用了多个项目，例如容器或集合。

我为此使用的约定是从左到右缩小范围。因此，万一项目可能是active或inactive。因此，项目有一个属性或属性是activeor inactive。缩小范围，我得到以下方案：

/items/active
/parent/id/active
于 2013-01-15T17:52:01.397 回答
4

对于你的第一个问题：

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

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

对于你的第二个问题：

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

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

于 2013-01-15T18:10:48.173 回答
2

当然，REST 原则并不关心 URL 的美学细节。它只是要求每个资源都应该是唯一可寻址的。

此外，使用查询参数来唯一地处理“某种”的东西违反了“参数”的语义，不是吗？参数应该是可选的、附加的和参数化的。例如，对一组项目进行详细搜索。

在某些情况下，您所写的内容可能有意义。这取决于。

在您的示例中，该项目真的是资源吗？如果没有，你可以这样做GET(POST) /parents/{parentId}。

如果parent是，比如说，一个布尔值，并且您想搜索其父项等于 true 的项目，那么使用参数是有意义的。但是由于您明确表示您想要一个具有特定 ID 的父级，我假设父级本身就是一个资源，我会使用您的选项 1 唯一地处理该资源。

我希望我说清楚了。

于 2013-01-15T17:38:46.507 回答
0

在我看来，没有规则可循。

items/{id}- 此约定适用于通过给定 id 获取项目。如果用户不提供 id 则返回 404 状态码。

items/id={id}&name={name}- 这种类型的约定适用于按给定条件搜索多个项目。如果没有找到任何项目，则不是404 情况，您只需说“我已成功找到任何符合您的搜索条件的内容”

于 2014-10-01T06:52:52.450 回答