RESTFul平面层次结构与搜索资源的动态层次结构

Question

我们正在创建REST API,目前我们有两种方法来定义资源.

基本上我们有Patients,Studies并且Imagesa Patient有n Studies和a 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具有patientId0).

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

 /webapi/images?q=imageName:mountain

是否有最佳实践方法或者是否有人遇到类似的情况？是一个搜索资源REST还是在平面方法中图像的关系不可见是不好的.

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

Answer 1

平面 URI 和分层 URI 都可以是 RESTful。问题出在别处。作为基于REST的假设URI是标识符的资源。

由什么资源标识/wepapi/patients/0/studies/12/images？12. 学习图片

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

可以更好吗？确实：

• wepapi（您获得资源表示的方式）与抽象资源无关。最 RESTful 的方法是为同一抽象资源的不同具体“表示”使用相同的 URI（Accept有关更多信息，请参阅 HTTP标头）。
• 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...），而不是在它们的结构中。

Answer 2

正如 Aur\xc3\xa9lien 指出的那样，设计 URI 结构不是 REST 问题。您应该遵循 URI 标准，该标准非常宽松。例如，它声明路径是分层的，而查询是 URI 的非分层部分。REST 的统一接口约束是关于使用标准解决方案，并且不存在像好的 URI 这样的标准，因此从 REST 角度来看，如何构造 URI 并不重要，因为它们不会被客户端解析（除非您将 URI 模板用于模板目的）。

\n\n

根据 HATEOAS 约束，您的客户端必须遵循服务发送的超链接。这些超链接必须使用有关其语义的元数据进行注释。该元数据可以是任何类型的链接数据。目前 IANA 链接关系是最典型的（通过非 RDF 格式），但您也可以使用 schema.org 操作等...（通过 RDF 格式）。因此客户端检查链接的元数据，而不关心 URI 结构。

\n\n

良好的 URI 结构仅对服务开发人员很重要。这很重要，因为有两件事：

\n\n

\n
• 它使路由变得更容易：如果 URI 可读，您可以更轻松地将端点映射到控制器。
\n
• 您可以检查是否将 URI 映射到资源而不是操作。如果您无法清除 URI 中的每一个动词，则说明有问题。例如，POST /users/123?update=true&partial=true body您无法删除update. 所以HTTP方法可能是错误的，因为动词去那里：PATCH /users/123 body解决了问题。大多数动词都可以简化为标准 HTTP 方法，就像GET, POST, PUT, DELETE, PATCH, etc...在实践中您（几乎）永远不需要新方法一样。
\n

\n\n

在我看来，扁平方法更好，因为它更容易解析。通过查找事物，您通常依赖于单个 id，而不是多个 id。

\n\n

/wepapi/patients/0/studies/12/images- 这是有道理的，因为您正在寻找第 0 个患者的第 12 个研究的图像。另一种方法是/images?patient=0&study=12或者 如果研究具有唯一的 id，则/images?study=0_12。顺便提一句。设计临时搜索查询并不是 REST 中最详细的部分。通过简单的查询，您可以使用 URI 的查询部分来管理它。

\n\n

REST 不是目前可以从实践中学到的东西。大多数人从未阅读或理解该理论，因此存在很多有缺陷的教程。您可能必须从菲尔丁论文和一些其他论文开始，例如这篇论文。有很多有趣且可能有用的项目仍在开发中，例如 Hydra、RESTdesc 等。因此，REST 实现远非一项复杂的技术。我们可能还需要15年，或者更长时间……

\n