Question

据我所知，在MVC模式和REST服务中，通常使用/items/{id}之类的URI，但在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的单个资源，如果不存在，则检索404。

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

关于你的第二个问题：

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

为了方便消费者，请使用rel="parent"创建link header和/或在子资源中包含uri。有关链接标头的示例，请参阅GitHub的pagination api。

Answer 2

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

此外，使用查询参数唯一地寻址“种类”的东西违反了“参数”的语义，不是吗？参数应该是可选的，附加的和参数化的。例如，对项目集合进行详细搜索之类的东西。

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

在您的示例中，项目确实是资源？如果没有，您可以GET(POST) /parents/{parentId}。

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

我希望我能说清楚。

Answer 3

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

items/{id} - 此约定适用于给定ID的GET项目。如果用户没有提供ID，则返回404状态代码。

items/id={id}&name={name} - 此类约定适用于按给定条件搜索多个项目。如果没有找到任何项目，那就是不 404情况，您只需说＆＃34;我成功找不到符合您搜索条件的内容＆＃34;