Are RESTful hierarchical URLs still preferred - in terms of extra overhead - over flat URLs?

Question

Let's say I have a website where users can upload and display their photos. The RESTful URL for a single image of this user will look like this:

http://api.gallery.com/users/{user-id}/images/{image-id} 

But the image id itself is already unique, so this url would already be good enough to get it:

 http://api.gallery.com/images/{image-id} 

From the point of view of REST, the first one will be favorable, but then I have to check that this image is valid from this user , because someone can change the url by changing the user ID to a stranger. In the latter case, I will not need to add this check, which means less processing time.

Is RESTful still preferable?

Answer 1

In short, both are preferred; Both can return the same thing, but the "context" is different.

Look at your urls:

• /users : all users
• /users/1 : user # 1
• /users/1/images : all images of user # 1
• /users/1/images/1 : user # 1 image # 1

All of the above URLs revolve around the user's resource. These are "all users", "user", "user images", etc.

• /images : all images
• /images/1 : image # 1

All of the above URLs revolve around the "image" resource. This is “all images” or “image”.

Now, at first glance, this difference may seem relatively insignificant, but when building the API, the difference can significantly affect data consumption.

For example, say you want to get a list of all the images of user # 1, which is preferable?

/users/1/images

or

/images?where=user.id eq 1

The first represents exactly what we want, more limited and more understandable, but this does not mean that we should not also support the second form, since the possibility of a request can be very useful.

Now, how about if you want to get a list of images with your associated user?

/users/???

or

/images?include=user

In this case, the first URL does not make much sense, since we are trying to get a list of images, not users, and the second URL represents exactly what we want,

Now, with regard to security, this should ideally be done in such a way that it is completely transparent to the consumer. The consumer should be able to say "I want all the images." and only get all the images that they have access to. If they try to access a specific resource that they do not have access to, the appropriate HTTP error code must be returned.

Answer 2

I think the second one is more RESTful for the reason that you are declaring. A URL is a hierarchy. The user ID is not part of the image identification, so why put it together in the ID?

Create the resource / users / {user-id} / images, which returns a list of URLs in the form / images / {image-id} to display the images that the user has uploaded, and you have the best of both worlds.

Answer 3

I think it all depends on semantics and intentions. It looks like you're talking about a secure resource, not a public one. In this case, your message is more explicit and has the least number of surprises when a more detailed format is used:

 http://api.gallery.com/users/{user-id}/images/{image-id} 

If this is a public resource, then it can only be identified by an image identifier, and a shorter format will be more logical:

 http://api.gallery.com/images/{image-id}