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

我们正在创建一个RESTAPI，目前有两种方法来定义资源

基本上我们有

患者

，

研究

和

图像

，其中

患者

有n个

研究

，而

研究

有n个

图像

分层方法

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

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

层次结构在URI中可见

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

 /webapi/search?q=imageName:mountain

平进近

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

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

层次结构由一个属性完成（例如，

study 12

的

patientId

为0）

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

 /webapi/images?q=imageName:mountain

是否有最佳实践方法，或者是否有人经历过类似的情况？是搜索资源REST，还是图像的关系在平面方法中不可见

---

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

平面URI和层次URI都可以是RESTful的。问题在别处。RESTful假设URI是资源的标识符

通过

/wepapi/patients/0/studies/12/images

识别哪些资源？研究的图像12

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

会更好吗？肯定是：

• wepapi

  （获取资源表示的方式）与抽象资源无关。最RESTful的方法是为同一抽象资源的不同具体“表示”使用相同的URI（有关更多信息，请参阅HTTP

  Accept

  headers）

• 患者/0

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

什么资源由

/search？q=imageName:mountain

标识？这些图像被命名为“山”

它真的是一个糟糕的标识符吗？不是真的。 会更好吗？肯定是：

• search

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

---

最后但并非最不重要的一点是，在

/studies/12/images

和

/images/？studies=12

之间进行选择，以便与

/studies/12

或

/images/？name=mountain

保持“一致性”，这纯粹是一种软件设计选择。采用更适合您的应用程序的解决方案。它与REST无关，因为URI不应该被黑客攻击（记住，它们应该是“不透明的”）。URI之间的链接是在它们的表示（JSON、XML、HTML…）中，而不是在它们的结构中。

正如Aurélien指出的那样，设计URI结构不是一个REST问题。您应该遵循URI标准，这是非常松散的。例如，它声明路径是层次结构的，而查询是URI的非层次结构部分。REST的统一接口约束是关于使用标准解决方案，并且没有像nice URI这样的标准，因此从REST的角度来看，构建URI并不重要，因为客户端不会解析URI（除非您使用URI模板进行模板化）

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

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

• 它使路由更容易：如果URI可读，则可以更容易地将端点映射到控制器
• 您可以检查您的URI是否映射到资源而不是操作。如果您无法清除URI中的每个动词，那么就有问题了。例如，通过

  POST/users/123？update=true&partial=true body

  不能删除

  update

  。因此，HTTP方法可能是错误的，因为动词指向那里：

  PATCH/users/123 body

  解决了问题。大多数动词都可以简化为标准的HTTP方法，如

  GET、POST、PUT、DELETE、PATCH等。

  因此在实践中，您几乎不需要新方法

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

/wepapi/patients/0/studies/12/images

-这很有意义，因为您正在查找第0位患者的第12次研究的图像。另一种方法是

/images？patient=0&study=12

，或者如果研究具有唯一id，则

/images？study=0\u 12

。顺便说一句，设计即席搜索查询并不是REST中最复杂的部分。通过简单的查询，您可以使用URI的查询部分来管理它

休息不是你目前可以从实践中学到的东西。大多数ppl从未阅读或理解该理论，因此有很多有缺陷的教程。比如说，你们可能得先读一篇论文和一些附加的论文。有许多有趣的、潜在有用的项目仍在开发中，如Hydra、RESTdesc等，所以REST实现远不是一种精心设计的技术。我们可能还需要15年或更长时间……

好主意。：-）我的意思是搜索实际上应该是一个HTTP动词，其主体包含标准查询语言上的查询。当前的方法，如

resources？q=“URL序列化”