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

发布于 2024-08-15 06:55:24 字数 767 浏览 2 评论 0原文

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

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

所以我的问题是,以下是否符合 REST:

我想公开有关研究出版物的信息(假设是同行评审的)。

可以通过以下 URI 访问:UNIVERSITY/publications/{my_publication}

但由于这篇论文是由一位在社会科学学院工作的研究人员撰写的,因此该出版物具有以下 URI 也是有意义的:UNIVERSITY/faculties/social_science/publications/{my_publication}

此外,由于该服务还公开了在大学工作的所有研究人员(例如 UNIVERSITY/researchers/{my_researcher}),因此该出版物可以命名为 UNIVERSITY/researchers/{my_researcher}/publications/{我的出版物}

这可能适用于多个用例,但您已经明白了。

这是否符合REST?

我可以保留这个并通过发送响应代码 303(“另请参阅”)和规范 URI(即 UNIVERSITY/publications/{my_publication})来解决这个困境吗?

先感谢您!

I'm writing a paper about implementing a REST service for a university's research papers and I have a small problem understanding the relationship between URIs and Resources.

It says, that a resource may have one URI or many. So here is my problem. I want to make this service very easy to use and to get around the information: a resource should be accessed from different entrypoints, but this will go against the concept, that every "URI designates exactly one resource".

So my question is if the following is it or is it not in accordance with REST the following:

I want to expose information about a research publication (let's say a peer reviewed).

This can be accessed by this URI: UNIVERSITY/publications/{my_publication}.

But since this paper is written by a researcher that works at the let's say Social Science Faculty, it will also make sense that the publication has this URI: UNIVERSITY/faculties/social_science/publications/{my_publication}.

Further more, as the service also expose all researchers working at the university (e.g. UNIVERSITY/researchers/{my_researcher}) it will also make sense that the publication can be named as UNIVERSITY/researchers/{my_researcher}/publications/{my_publication}.

This could go on with multiple usecases, but you get the idea.

Is this in accordance with REST or not?

Can I keep this and solve the dilemma by sending a response code 303("See also") along with the canonical URI (that will be UNIVERSITY/publications/{my_publication}).

Thank you in advance!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

流心雨 2024-08-22 06:55:24

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

不,事实并非如此。 “每个手指都属于一只手”并不意味着“每只手都有一个手指”。 “每个 URI 都指定一个资源”并不意味着“每个资源都由一个 URI 指定”。

也就是说,重定向到规范 URI 将改善某些用例(例如,两个用户在美味上为同一篇论文添加书签,他们从不同的查询到达那里)。

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

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

It says, that a resource may have one URI or many. So here is my problem. I want to make this service very easy to use and to get around the information: a resource should be accessed from different entrypoints, but this will go against the concept, that every "URI designates exactly one resource"

No it doesn't. "Every finger belongs to exactly one hand" does not imply "every hand has exactly one finger". "Every URI designates exactly one resource" does not imply "every resource is designated by exactly one URI".

That said, a redirect to a canonical URI would improve some use cases ( such a two users bookmarking the same paper on delicious, having arrived there from different queries ).

You also seem to be thinking about constructing URLs via hierarchic patterns, rather than anything about REST. REST applications use "hypertext as the engine of application state". The form of the URI is irrelevant, what matters is that it is navigable from the representation returned at the application's entry point. Fielding (the inventor of REST) makes this clear in his blog REST APIs must be hypertext-driven as an anti-pattern causing coupling between client and server:

A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server).

牛↙奶布丁 2024-08-22 06:55:24

这是一个经常争论的话题,我相信这种混乱是基于试图理解 HTTP URI 实际指向的内容。根据我的阅读,这成为一个非常棘手的话题,比我聪明得多的人在这个问题上争论了很多年。

这里是关于http-range-14 问题。

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

所以答案是肯定和否定,同一资源可以有多个 URI,并且所有 URI 都可有效表示概念,但只有一个应该实际返回物理表示。

这与 Roy Fielding 最近在谈论在 URI 中使用“.xml”和“.json”时发表的评论是一致的。他非常清楚地指出 http://www.example.org/myresource.xmlhttp://www.example.org/myresource.json 指的是两个不同的资源,因为它们都返回 200。但是,当您在 http://www.example.org/myresource 上使用内容协商时,您可以检索同一资源的两种不同表示形式。

This is a frequently debated topic and I believe the confusion is based on trying to understand what does an HTTP URI actually point to. Based on my readings this becomes a really hairy topic and people way smarter than myself debated for many years on the subject.

Here is the a summary page of all of the discussion on the http-range-14 issue.

My naive interpretation of the final conclusion of this issue is that there should only be a single URI that returns a physical "information resource" with a 200. However, there can be many URIs that refer to the resource as a pure concept. Returning 303 allows you to link the concept to "information resource".

So the answer is yes and no, there can be multiple URIs for the same resource and all are valid for representing the concept, but only one should actually return the physical representation.

This is consistent with a recent comment from Roy Fielding when talking about using ".xml" and ".json" in URIs. He stated quite clearly that http://www.example.org/myresource.xml and http://www.example.org/myresource.json are refering to two different RESOURCES because they are both returning a 200. However, when you use content negotiation on http://www.example.org/myresource you could retrieve two different representations of the same resource.

乖乖公主 2024-08-22 06:55:24

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

您可以将 UNIVERSITY/publication/{publication} 作为出版物资源的资源名称模式,并将 UNIVERSITY/faculties/{faculty}/publications 作为命名资源的模式是特定院系的出版物清单。同样,UNIVERSITY/researchers/{researcher}/publications 可以是特定人员创作的出版物列表的资源名称模式。

While each publication resource should have one and only one resource name (URI), you're free to create resources that are queries and that return lists of other resource names.

You could have UNIVERSITY/publication/{publication} as the resource name pattern for publication resources, and UNIVERSITY/faculties/{faculty}/publications as the pattern for naming resources that are lists of publications for particular faculties. Likewise UNIVERSITY/researchers/{researcher}/publications could be the resource name pattern for the lists of publications authored by a particular person.

陈甜 2024-08-22 06:55:24

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

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

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

It says, that a resource may have one URI or many. So here is my problem. I want to make this service very easy to use and to get around the information: a resource should be accessed from different entrypoints, but this will go against the concept, that every "URI designates exactly one resource".

I don't think there's any contradiction here. A URI can point to at most one resource, but many URIs can point to the same resource. A many-to-one relationship between URIs and resources, if you will.

That said, I wouldn't freak out too much over whether your application is RESTful or not. It's just a design principle. Here is a nice article by a guy who argues that REST isn't really intended for humans with web browsers anyway: http://starkravingcoder.blogspot.com/2009/01/where-are-rest-frameworks.html

独﹏钓一江月 2024-08-22 06:55:24

吉姆·费兰斯+1。

此外,每个资源只有一个 URI 将使您更容易在站点内创建链接。我读到,搜索引擎也更喜欢内容不要在不同的 URI 上重复。

+1 to Jim Ferrans.

Also, having exactly one URI per resource will make it easier to create links within your site. I have read that search engines prefer content not to be repeated at different URIs too.

迟到的我 2024-08-22 06:55:24

您需要了解资源与其代表的实体之间的区别。
Roy Fielding 在他的论文第 5.2.1.1 节中写道:

资源是到一组实体的概念映射,而不是
对应于任意特定点的映射的实体
时间。

由于所有资源的语义都略有不同,因此我认为可以将其视为 RESTful。根据您的媒体类型的结构,您可以使用规范链接关系来指示“首选 uri”。

You need to see the difference between a resource and the entity it represents.
Roy Fielding writes in his dissertation, section 5.2.1.1:

A resource is a conceptual mapping to a set of entities, not
the entity that corresponds to the mapping at any particular point in
time.

Since all of your resources carry slightly different semantics, it can be considered RESTful it my opinion. Depending on the structure of your media type you could use the canonical link relation to indicate the "preferred uri".

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文