如何組織資源在Web應用程序的URL結構

Question

現狀

我開發的PHP的在線訂單管理系統應用程序，我需要通過URL方案設計REST資源映射。

我有典型的資源：

• 客戶（有訂單）
• 訂單（有票）
• 票務（有消息）
• 消息

我想到的是這樣的：

1. 客戶概況：

   example.com/customers/{customer-ID} 
   

2. 訂單爲{客戶ID}：

   example.com/customers/{customer-ID}/orders 
   

3. {或DER-ID}：

   example.com/customers/{customer-ID}/orders/{order-ID}/tickets 
   

4. 消息{票ID}

   example.com/customers/{customer-ID}/orders/{order-ID}/tickets/{ticket-ID}/messages 
   

發現

谷歌搜索的

有一天，我發現這些qutoes：

1. 的用戶名後面的命名空間功能，如

   example.com/{username}/followers 
   

   是公共功能屬於每個用戶單獨偉大的解決方案。

2. 私人的東西，比如帳戶設置，不應該的用戶名背後命名空間，並且應該只出現/account或/settings之後。

3. 這是最好保持基本資源的URL結構儘量緊湊，。過濾器，分揀要求，先進搜索和分頁可以爲查詢參數得到落實。

4. 的查詢字符串應該被視爲一個可選除了頁面;該網址應該能夠生成有效且有用的網頁，即使該網頁已被刪除。

5. 在一個良好的，破解的URL，人類可以調整或刪除路徑的部分，並從您的網站預期的結果。它們可以讓您的訪問者更好地定位您的頁面，並使他們輕鬆向上移動。

6. 通過在你的路徑早就嵌入一個唯一的ID，你可以在需要時有長，完全採用描述性網址，但仍享受較短的網址的可靠性和ID查找的速度。

7. 添加多個關鍵字網址可以與SEO的幫助，但它會混淆用戶。此外，您很快就會冒着被標記爲關鍵字垃圾郵件發送者的風險。

問題

• 我做的事情錯了嗎？
• 我應該避免命名空間客戶，訂單，門票和消息？
• 它是否有任何真正的重大安全問題？

在此先感謝！

Answer 1

如果您描述的所有關係都是一對多關係（而非多對多關係），那麼我並不真正看到通過擁有這些關鍵字所帶來的收益，例如，包含客戶ID，而訂單ID是衆所周知。這是冗餘信息，並且不會在控制器中提供其他有用的信息。

事實上，它可能會導致比預期更多的複雜性，因爲現在您必須處理可能是客戶訂購ID不匹配的情況。您現在必須檢查所有這些條件，並在發生不良情況時返回錯誤的請求響應。爲什麼要增加開銷？

也許只是：

客戶概況：

example.com/customers/{customer-ID} 

訂單爲{客戶ID}：

example.com/customers/{customer-ID}/orders 

門票{訂單編號}：

example.com/orders/{order-ID}/tickets 

留言{ticket-ID}

example.com/tickets/{ticket-ID}/messages 

如果您有多對多的關係，這可能會改變。例如，假設客戶可以輸入涵蓋多個訂單的單個票據（這意味着現在票據與訂單本身的關係比訂單本身更多），那麼除了上面顯示的訂單之外，您可能還需要類似以下的URL：

查看所有訂單給定的票：

example.com/tickets/{ticket-ID}/orders 

查看所有的門票的客戶：

example.com/customer/{customer-ID}/tickets 

Answer 2

我做的事情錯了嗎？

這取決於。你似乎在正確的軌道上，但你最好決定你的服務應該首先提供什麼功能。否則，您最終可能會實現無限數量的url（資源）。例如，如果您需要在所有客戶端中公開一個訂單列表，您將希望使用查詢字符串參數的example.com/orders資源來指定搜索條件。否則，必須首先查詢所有客戶端，然後在循環中發送請求到example.com/customers/{customer-ID}/orders以獲取所有客戶端的所有訂單。 因此，首先考慮您的服務需要展示哪些功能，然後爲其設計資源。

它是否有任何真正的重大安全問題？

它與url（資源）設計無關。身份驗證和授權信息通常位於http標頭中。

也請考慮添加版本信息到您的網址。事實證明，當你必須支持你的服務的幾個版本是超級有用

example.com/v1/customers/{customer-ID}/orders 

或

v1.example.com/customers/{customer-ID}/orders 

等

最後，如果你要支持多表示爲資源，例如，您可能會將客戶端列表作爲JSON，XML，HTML等返回，因此最好在URL中指定它。所以決定你的默認表示格式，並公開爲example.com/customers，然後添加格式信息的URL的末尾，如果你支持其他

example.com/customers.xml 

或

example.com/customers.html 

等

希望它幫助！

我認爲包括URL標識可能不是一個很好的做法

那麼，有兩種主要的方法，並都有它利弊和prons。第一個是使用名稱或簡短資源摘要而不是ID。例如，您可以使用其名稱example.com/customers/amazon而不是客戶端ID，其中amazon是您的客戶端名稱。該方法的另一個很好的例子是新聞網站，如果你通過cnn.com導航，你會看到每一篇文章的網址包含文章標題http://edition.cnn.com/2016/06/10/middleeast/israel-tel-aviv-shooting/index.html - 「特拉維夫犯罪嫌疑人發現藏在休班警察之家」

這是從SEO的角度來看大而且網址變得更具描述性和人性化。但是，如果你必須改變你的客戶名稱，它應該改變網址，並且存在破壞客戶的巨大風險。除此之外還有很多事情要記住，同時實施的辦法：

• 你應該正確地驗證客戶的名稱，以便他們確定要添加到URL
• 你不應該允許更改客戶名稱或妥善處理通過返回301（「感動永久」），並在指定位置標頭中的新的URL，以便客戶端知道新的URL
• 等

標識方法的主要優點是，網址是總是靜止的，你不必擔心上面的實現東西。

兩種方法都是從靜止的角度有效，所以它的你來決定