URL結構的最佳實踐/標準

Question

我的建築，項目站點，每個項目有一個頁面，例如：

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

每個項目可以有多個子（和分分，分子分頁），例如一本書可以有一個blurb，一部電影可以有一個畫廊，一個遊戲也可以有一個畫廊。

我的問題是，圍繞與物品相關的頁面構建網址時是否存在任何標準或最佳做法？例如：

website.com/film/456/gallery 

凡亞頁面出現後的項目，或：

website.com/film/gallery/456/ 

處的項目是URL的最後一部分。

沒有人有任何關於的信息爲什麼哪種方法最好或者是否存在任何Web標準？這似乎是一個明顯的事情，但我很難決定，我可以考慮每種方法的優點和缺點 - 雖然我傾向於前一種選擇，因爲這意味着以下用戶路徑將匹配URL：

load website.com - >點擊「電影」（website.com/films） - >點擊「電影」（website.com/film/123） - >點擊圖庫（website.com/film/123/gallery）

但是，它似乎...關閉，也許不一致。

Answer 1

你是對的，前面的URL是「更好的」並且部署得更加廣泛。我不認爲你會發現在任何標準;它更像是一種慣例。大多數涉及REST的文章和書籍都是這樣做的。

如您所說，原因是URL中的路徑組件與資源和子資源的結構相匹配。具體而言，以下所有的應該是有效的URL：

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

特別要注意的那就是books/123,不是book/123就像你有。我看到了單數，但恕我直言，複數更好。

對於URL /books

• 一個GET得到所有書籍，但你可以限制與查詢參數，例如書籍/books?author=alice
• POST添加一本新書（帶有服務器生成的ID）。

對於URL /books/123

• 一個GET獲取特定的書
• 一個PUT與ID代替書（或添加一本書與該客戶端生成的ID）

現在，如果一本書有blurb和blurb是唯一只對特定的書那麼你將添加以下URL：

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

你可以做電影和畫廊一樣，提供每家畫廊屬於一個單電影。但是，如果畫廊存在多部影片，那麼您將使/galleries成爲頂級網址。從電影導航到畫廊仍然沒問題。你不會有結構化的網址。你會得到，而不是通過GET含薄膜456畫面中的所有畫廊

• website.com/galleries?film=456

一般的規則是，如果你擁有的子資源的所有權關係您可以使用結構化網址，但是如果頂級項目之間的關係較鬆，查詢參數就可以。不要陷入RESTful URL沒有查詢參數的常見誤解。他們是這樣。 :)

現在終於，直接回答你的問題：website.com/films/galleries/456是不是一個很好的網址恕我直言，因爲`website.com/films/galleries/是不是很有用。事實上，我認爲這相當難看。這意味着什麼？所有畫廊？如果是這樣，它應該是website.com/galleries。

再次，我不認爲這是標準化的任何地方，但它感覺非常常見和傳統。