RESTFul Flat Hierarchy vs. Dynamic Hierarchy for Search Resource

Question

我们正在创建一个 REST API，我们目前有两种定义资源的方法。

基本上我们有 Patients , Studies和 Images哪里Patient有 n Studies和一个 Study有 n Images .

分层方法

/webapi/patients/0/studies/12/images 

层次结构在 URI 中可见

要搜索所有图像，我们需要一个搜索资源

 /webapi/search?q=imageName:mountain

平进

/webapi/patients/0
/webapi/studies/12
/webapi/images/

层次结构由属性完成(例如 study 12 的 patientId 为 0)。

要搜索所有图像，我们可以搜索资源本身:

 /webapi/images?q=imageName:mountain

是否有最佳实践方法或是否有人遇到过类似的情况？搜索资源是 REST 还是在平面方法中看不到图像的关系是不好的。

我们还需要考虑移动和修改。

Answer 1

平面 URI 和分层 URI 都可以是 RESTful。问题出在别处。 RESTful 假设 URI 是资源的标识符。
/wepapi/patients/0/studies/12/images 标识了哪些资源? 12. 学习图片

它真的是一个糟糕的标识符吗？并不真地。

可以更好吗？确实:

wepapi (您获得资源表示的方式)与抽象资源无关。最 RESTful 的方法是为同一抽象资源的不同具体“表示”使用相同的 URI(有关更多信息，请参见 HTTP Accept header )。

patients/0不需要识别这些图像。您可能认为客户端软件通过解析 URI 来获取此数据会很酷，但是……他们不应该这样做。 URI 被称为“不透明”。

/search?q=imageName:mountain 标识了哪些资源?名为“山”的图像。

它真的是一个糟糕的标识符吗？并不真地。
可以更好吗？确实:

search看起来像一个动词，它应该会在 RESTful 设计师的头脑中引发很多警告。在某种程度上，我们可以说 URI 标识“搜索”或“搜索结果”(名词而不是动词)，但认为它标识“图像”更安全。

最后但并非最不重要的是，在 /studies/12/images 之间进行选择和 /images/?studies=12为了与 /studies/12 中的任一个“一致”或 /images/?name=mountain纯粹是一种软件设计选择。采取更适合您的应用程序的解决方案。它与 REST 无关，因为 URI 不应该被黑客攻击(请记住，它们应该是“不透明的”)。 URI 之间的链接在它们的表示中(JSON、XML、HTML...)，而不是在它们的结构中。