我可以拥有没有集合URI的REST元素URI吗？

Question

一个基本的REST问题..我设计了一个REST API，并希望能够根据书籍ID获取书籍推荐列表（即客户端将书籍ID = w发送到服务器和服务器回复以及推荐列表书籍，id = x，y，z）。

我认为有两种方法可以做到这一点：

1. /recommendation?bookId=thetitle
2. /recommendation/thetitle

选项2对我来说似乎有点干净，但我不确定它是否会被认为是好的REST设计？因为/recommendation/thetitle看起来像一个元素URI，而不是集合URI（尽管在这种情况下它会返回一个集合）。此外，资源的第一部分（/recommendation）本身没有任何意义。

感谢任何建议。

Answer 1

此类网址模式与REST无关。 REST的定义属性都不需要可读的URL。

同时，其中一个核心原则（HATEOAS），如果正确使用，则允许API客户端（应用程序，而不是人！）浏览API并获取执行所需的应用程序状态或资源转换所需的每个链接基于众所周知的消息格式的状态。

如果您认为您的API必须具有可读的URL，则表明它的设计可能根本不是REST，这是一个好兆头。这意味着开发人员需要了解URL结构并在客户端应用程序中的某处对其进行硬编码。 REST原则上应该避免的东西。

引用Roy Fielding的the docs：

  

REST API 不得定义固定资源名称或层次结构（客户端和服务器的明显耦合）。服务器必须能够自由控制自己的命名空间。相反，允许服务器通过在媒体类型和链接关系中定义这些指令来指示客户端如何构造适当的URI，例如在HTML表单和URI模板中完成的。 [这里的失败意味着客户端由于带外信息而假定资源结构，例如特定于域的标准，这是面向数据的，与RPC的功能耦合等效。]

显然，无论您的API实际上是多么REST，都没有什么能阻止您实际使URL有意义。即使它是出于不受REST本身决定的目的（查看正确RESTful API的客户端留下的日志对于人类来说可能更容易，如果它们是可读的，那么就是我的头脑。）

最后，如果您可以开发一个不完全REST的Web API，并且您希望客户的开发人员阅读此类文档并关注路径构建，那么您实际上可能会从可理解的URL中受益。根据{{​​3}}，这在所谓的级别0-3 的API中非常有用。

在REST方面，重要的是如何利用底层协议（在这种情况下为HTTP）以及它允许​​您做什么。如果我们从这个角度考虑您的示例，SQLConn2.Open(); 似乎更可取。这是因为使用查询参数可能会阻止浏览器缓存响应（如果您正在编写JS客户端，则很重要）或代理，从而使重用现有工具和基础结构变得更加困难。