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的{{1}}为0）。

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

patientId

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

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

Answer 1

平面和分层URI可以都是RESTful。问题出在其他地方。 RESTful假设URI是资源的标识符 。

/wepapi/patients/0/studies/12/images确定了哪些资源？研究图像12。

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

可能会更好吗？肯定：

wepapi（获取资源表示的方式）与抽象资源无关。最RESTful的方法是为不同的具体＆＃34;表示＆＃34;提供相同的URI。相同的抽象资源（有关详细信息，请参阅HTTP Accept标头）。
patients/0。您可能认为客户端软件通过解析URI来获取此数据会很酷，但是......他们不应该这样做。 URI被称为＆＃34;不透明＆＃34;。

/search?q=imageName:mountain确定了哪些资源？名为＆＃34; mountain＆＃34;。

的图像

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

search看起来像一个动词，它应该在RESTful设计师的头脑中引发很多警告。在某种程度上，我们可以说URI识别＆＃34;搜索＆＃34;或＆＃34;搜索结果＆＃34; （一个名词而不是一个动词），但考虑到它识别＆＃34;图像＆＃34;更安全。

最后但并非最不重要的一点是，在/studies/12/images和/images/?studies=12之间进行选择，以便成为＆＃34;连贯的＆＃34;使用/studies/12或/images/?name=mountain纯粹是软件设计选择。采用对您的应用程序来说更优雅的解决方案。它与REST无关，因为URI不应该被黑客攻击（记住，它们应该是＆＃34;不透明＆＃34;）。 URI之间的链接在它们的表示中（JSON，XML，HTML ......），而不是它们的结构。

Answer 2

正如Aurélien指出的那样，设计URI结构不是REST问题。你应该遵循URI标准，这是非常宽松的。例如，它声明路径是分层的，查询是URI的非分层部分。 REST的统一接口约束是关于使用标准解决方案，并且没有这样的标准作为好的URI，因此从REST的角度来看，构造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, etc...，所以在实践中你几乎不需要新的方法。

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

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

REST不是您目前可以从实践中学到的东西。大多数人从未阅读或理解该理论，因此有很多有缺陷的教程。您可能必须从Fielding dissertation和一些其他论文开始，例如this one。有许多有趣且可能有用的项目仍在开发中，如Hydra，RESTdesc等。因此，REST实现远非精心设计的技术。我们可能还需要15年或更长时间......

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

2 个答案: