REST - multiple URI for the same resource (???)

Question

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!

Answer 1

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).

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

+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.

Answer 6

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".