REST - 同一资源的多个URI(???)

Question

我正在写一篇关于为大学的研究论文实现REST服务的论文,我在理解URI和资源之间的关系时遇到了一个小问题.

它说,资源可能有一个或多个URI.所以这是我的问题.我想使这项服务非常容易使用并绕过信息:应该从不同的入口点访问资源,但这违背了每个"URI指定一个资源"的概念.

所以我的问题是,如果以下是它或不符合REST的以下内容:

我想公开有关研究出版物的信息(让我们说同行评审).

这可以通过此URI访问:UNIVERSITY/publications/{my_publication}.

但是,由于这篇论文是由一位在社会科学系工作的研究人员撰写的,因此该出版物也有这个URI的意义:大学/学院/社会科学/出版物/ {my_publication}.

此外,由于该服务还暴露了在大学工作的所有研究人员(例如大学/研究人员/ {my_researcher}),因此该出版物可以命名为大学/研究人员/ {my_researcher}/publications/{my_publication}也是有意义的.

这可以继续使用多个用例,但你明白了.

这是否与REST一致？

我可以保留这个并通过发送响应代码303("另请参阅")以及规范URI(即大学/出版物/ {my_publication})来解决困境.

先感谢您!

Answer 1

它说,资源可能有一个或多个URI.所以这是我的问题.我想使这项服务非常容易使用并绕过信息:应该从不同的入口点访问资源,但这违背了每个"URI指定一个资源"的概念.

不,不."每个手指完全属于一只手"并不意味着"每只手只有一根手指"."每个URI都指定一个资源"并不意味着"每个资源都由一个URI指定".

也就是说,重定向到规范的URI会改善一些用例(例如,两个用户将同一篇论文加入书签,从不同的查询到达那里).

您似乎也在考虑通过层次结构模式构建URL,而不是关于REST的任何内容.REST应用程序使用"超文本作为应用程序状态的引擎".URI的形式无关紧要,重要的是它可以从应用程序入口点返回的表示中导航.Fielding在他的博客中明确表示REST API必须是超文本驱动的,作为反模式导致客户端和服务器之间的耦合:

REST API不能定义固定资源名称或层次结构(客户端和服务器的明显耦合).

Answer 2

这是一个经常被争论的主题,我认为混淆是基于试图理解HTTP URI实际指向的内容.根据我的阅读,这成为一个非常毛茸茸的话题,人们的方式比我自己多年来在这个问题上的辩论更聪明.

这是关于http-range-14问题的所有讨论的摘要页面.

我对该问题最终结论的天真解释是,应该只有一个URI返回带有200的物理"信息资源".但是,可以有许多URI将资源称为纯概念.返回303允许您将概念链接到"信息资源".

所以答案是肯定的,不是,同一资源可以有多个URI,并且所有URI都有效用于表示概念,但实际上只有一个应该返回物理表示.

这与Roy Fielding最近在谈论在URI中使用".xml"和".json"时的评论是一致的.他非常清楚地说明http://www.example.org/myresource.xml并且http://www.example.org/myresource.json正在引用两个不同的资源,因为它们都返回200.但是,当您使用内容协商时,http://www.example.org/myresource您可以检索同一资源的两个不同表示.

Answer 3

虽然每个发布资源应该只有一个资源名称(URI),但您可以自由创建查询资源并返回其他资源名称列表.

您可以使用UNIVERSITY/publication/{publication}作为发布资源的资源名称模式,以及UNIVERSITY/faculties/{faculty}/publications作为特定功能的发布列表的命名资源的模式.同样UNIVERSITY/researchers/{researcher}/publications可以是特定人员撰写的出版物列表的资源名称模式.

Answer 4

它表示，一种资源可以有一个或多个 URI。所以这是我的问题。我想让这个服务非常易于使用并绕过信息：应该从不同的入口点访问资源，但这违背了每个“URI 指定一个资源”的概念。

我不认为这里有任何矛盾。一个 URI 最多可以指向一个资源，但多个 URI 可以指向同一个资源。URI 和资源之间的多对一关系（如果您愿意的话）。

也就是说，我不会太担心您的应用程序是否是 RESTful。这只是一个设计原则。这是一篇不错的文章，作者认为 REST 并不是真正适合使用 Web 浏览器的人类： http://starkravingcoder.blogspot.com/2009/01/where-are-rest-frameworks.html