RESTFul Flat Hierarchy vs. Dynamic Hierarchy for Search Resource [英] RESTFul Flat Hierarchy vs. Dynamic Hierarchy for Search Resource

问题描述

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

We are creating a REST API and we currently have two approaches for defining the resources.

基本上我们有 Patients、Studies 和 Images，其中 Patient 有 n Studies 和一个 Study 有 n Images.

Basically we have Patients, Studies and Images where a Patient has n Studies and a Study has n Images.

分层方法

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

层次结构在 URI 中可见

The hierarchy is visible in the URI

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

To search for all images we would need a search resource

 /webapi/search?q=imageName:mountain

扁平化方法

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

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

The hierarchy is done by an attribute (for example study 12 has a patientIdof 0).

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

To search for all images we can search on the resource itself:

 /webapi/images?q=imageName:mountain

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

Is there a best practice approach or does anyone have experienced a similar scenario? Is a search resource REST or is it bad that the relation from an image is not visible in the flat approach.

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

Also we need to think about move and modification.

推荐答案

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

Flat and hierarchical URIs could be both RESTful. The problem is elsewhere. Being RESTful suppose that URIs are identifiers of resources.

/wepapi/patients/0/studies/12/images 标识了哪些资源?研究图像 12.

What resource is identified by /wepapi/patients/0/studies/12/images? The images of studies 12.

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

Is it really a bad identifier? Not really.

会更好吗?肯定的:

• wepapi(获取资源表示的方式)与抽象资源无关.最 RESTful 的方法是为同一抽象资源的不同具体表示"使用相同的 URI(有关详细信息，请参阅 HTTP Accept 标头).
• patients/0 不需要识别这些图像.您可能认为客户端软件通过解析 URI 来获取此数据会很酷，但是……他们不应该这样做.URI 被称为不透明".

• wepapi (the way you get a representation of the resource) has nothing to do with the abstract resource. The most RESTful approach would be to have the same URI for different concrete "representations" of the same abstract resource (see HTTP Accept headers for more information).
• patients/0is not needed to identify those images. You might think that it would be cool for client software to get this datum by parsing the URI, but... they are not supposed to do that. URI are said to be "opaque".

/search?q=imageName:mountain 标识了什么资源?名为山"的图像.

What resource is identified by /search?q=imageName:mountain? The images that are named "mountain".

它真的是一个糟糕的标识符吗?并不真地.可以更好吗?肯定的:

Is it really a bad identifier? Not really. Could it be better? Definitely:

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

• search looks like a verb, which should raise a lot of warnings in a RESTful designer mind. In a way, we could say that the URI identify "a search" or "search results" (a noun and not a verb), but it is safer to consider that it identifies "images".

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

Last but not least, choosing between /studies/12/images and /images/?studies=12 in order to be "coherent" with either /studies/12 or /images/?name=mountain is purely a software design choice. Take the solution that will be the more elegant for your application. It has nothing to do with REST, since URIs are not supposed to be hacked (remember, they are supposed to be "opaque"). The links between URIs are in their representations (JSON, XML, HTML...), not in their structure.

这篇关于RESTFul Flat Hierarchy vs. Dynamic Hierarchy for Search Resource的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！