URL Structure best practice / standard

I'm building a site that has items, with each item having a page, for example:

website.com/book/123
website.com/film/456
website.com/game/789

Each item can have multiple sub (and sub-sub, sub-sub-sub) pages, for example a book could have a blurb, a film could have a gallery and a game could also have a gallery.

My question is, does any sort of standard or best practice exist around structuring the URLs for pages associated with an item? For example:

website.com/film/456/gallery

Where the sub page comes after the item, or:

website.com/film/gallery/456/

where the item is the very last part of the URL.

Does anyone have any information on why which approach is best or if any web standard exists? It seems an obvious thing but I'm struggling to decide, I can think of pros and cons for each approach -- although I'm leaning towards the former option because it means the following user path would match the URL:

load website.com -> click "films" (website.com/films)-> click "a film" (website.com/film/123) -> click gallery (website.com/film/123/gallery)

but something about it seems... off, inconsistent maybe.

You are correct that the former URL is "better" and is more widely deployed. I don't think you would find this documented in any standard; it is rather more of a convention. Most articles and books covering REST do it that way.

The reason for this is, as you say, that the path components in the URL match the structure of resources and sub-resources. In particular, all of the following should be valid URLs:

• website.com/
• website.com/books
• website.com/books/123

In particular, note that it is books/123, not book/123 like you have. I have seen the singular but IMHO the plural is better.

For the URL /books

• a GET gets all books, but you can restrict the books with query parameters, e.g. /books?author=alice
• a POST adds a new book (with a server-generated id).

For the URL /books/123

• a GET gets that particular book
• a PUT replaces the book with that id (or adds a book with that client-generated id)

Now if a book has blurbs and the blurbs are unique only to a particular book then you will add the following URLs:

• website.com/books/123/blurbs
• website.com/books/123/blurbs/72

You can do the same for films and galleries, provided each gallery belonged to a single film. But if galleries existed for multiple films, then you would make /galleries a top-level URL. Navigating from a film to a gallery would still be fine. You wouldn't have a structured URL. You would instead get all galleries containing pictures from film 456 via a GET to

• website.com/galleries?film=456

The general rule is that if you have an ownership relation for the subresources you can use structured urls, but if there is a looser relationship among top-level items, query parameters are fine. Don't fall into the common misconception that RESTful URLs don't have query parameters; they do. :)

Now finally, to directly answer your question: website.com/films/galleries/456 is not a good URL IMHO because `website.com/films/galleries/ is not very useful. In fact I think it is rather ugly. What would it mean? All galleries? If so, it should be website.com/galleries.

Again I don't think this is standardized anywhere, but it feels very common and conventional.