Designing a REST hierarchy where there is duplicate data

Question

We are having a debate on how to design REST endpoints. It basically comes down to this contrived example.

Say we have:

/netflix/movie/1/actors <- returns actors A, B and C
/netflix/movie/2/actors  <- returns actors A, D, and E

Where the actor A is the same actor.

Now to get the biography of the actor which is "better" (yes, a judgement call):

/netflix/movie/1/actors/A
/netflix/movie/2/actors/A

or:

/actors/A

The disagreement ultimately stems from using Ember.js which expects a certain hierarchy -vs- the desire to not have multiple ways to access the same data (in the end it would truly be a small amount of code duplication). It is possible to map Ember.js to use the /actors/A so there is no strict technical limitation, this is really more of a philosophical question.

I have looked around and I cannot find any solid advice on this sort of thing.

See also [What are best practices for REST nested resources?](https://stackoverflow.com/questions/20951419/what-are-best-practices-for-rest-nested-resources) — Grigory Kislin, Sep 07 '19 at 11:05

score 4 · Answer 1 · answered Jun 04 '13 at 20:06

I faced the same problem and went for option 2 (one "canonical" URI per resource) for the sake of simplicity and soundness (one type of resource per root).

Otherwise, when do you stop? Consider:

/actors/
/actors/A
/actors/A/movies
/actors/A/movies/1
/actors/A/movies/1/actors
/actors/A/movies/1/actors/B
...

score 3 · Accepted Answer · answered Jun 04 '13 at 20:05

3

I would, from an outsiders perspective, expect movies/1/actors/A to return information specific to that actor FOR that movie, whereas I would expect /actors/A to return information on that actor in general.

By analogy, I would expect projects/1/tasks/1/comments to return comments specific to the task - the highest level of the relationship via its url.

I would expect projects/1/comments to return comments related to the lower level project, or to aggregate all comments from the project.

The analogy isn't specific to the data in question, but I think it illustrates the point of url hierarchy leading to certain expectations about the data returned.

answered Jun 04 '13 at 20:05

Squadrons

2,467
5
25
36

In this case it would be the biography of the actors work as a whole, not anything specific to the movie. In the context of the actual app there is no difference on the data that would be returned from either end point. – TofuBeer Jun 04 '13 at 20:07
Then I would absolutely prefer actors/A. Other user's answers below cover something I did, namely endless strings of /actors/A/movies/1/actors/B, which is just odd. – Squadrons Jun 04 '13 at 20:09
2

Having one only URI for a resource is important for caching. – Darrel Miller Jun 05 '13 at 01:14

score 3 · Answer 3 · answered Jun 04 '13 at 20:05

I would in this case clearly prefer /actors/A.

My reasoning is, that /movie/1/actors reports a list. This list, beeing a 1-n mapping between movie and actors, is not ment to be a path with further nodes. One simply does not expect to find actors in the movie tree.

You might one day implement /actors/A/movies returning 1 & 2, and this would make you implement URLs like /actors/A/movies/2 - and here you get recursion: movie/actor/movie/actor.

I´d prefer one single URL per object, and one clear spot where the 1-n mapping can be found.

Designing a REST hierarchy where there is duplicate data

3 Answers3