連通性的好處是什麼？

Question

面向資源的架構（ROA）定義的連通性的好處是什麼？我理解它的方式，Connectedness的關鍵是能夠僅使用根URI來爬行整個應用程序狀態。

但是真的有用嗎？

例如，假設HTTP GET http://example.com/users/joe返回到http://examples.com/uses/joe/bookmarks的鏈接。

除非你正在編寫一個愚蠢的網絡爬蟲（即使那麼我想知道），你仍然需要教客戶每個鏈接在編譯時的含義。也就是說，客戶端需要知道「書籤URI」向書籤資源返回URI，然後將控制權交給特殊的書籤處理算法。您不能僅僅將鏈接盲目地傳遞給某些常規客戶端方法。因爲你需要這個邏輯反正：

1. 什麼是客戶端在運行時與在編譯時提供它搞清楚的URI的區別（使http://example.com/users/bookmarks根URI）？

2. 爲什麼使用http://example.com/users/joe/bookmarks/2優先使用id="2"？

我能想到的唯一的好處是改變非根URI的路徑，通過時間的能力，但這種休息緩存鏈接，以便它不是一個真正理想的反正。我錯過了什麼？

Answer 1

你是對的，改變尤里斯是不可取的，但它確實發生，並且使用完整的Uris而不是構建它們使變更更容易處理。

另一個好處是您的客戶端應用程序可以輕鬆地從多個主機檢索資源。如果您允許客戶端構建URI，則客戶端需要知道某些資源駐留在哪個主機上。當所有資源都存在於單個主機上時，這並不是什麼大問題，但當您彙總來自多個主機的數據時，這變得更加棘手。

我最後的想法是，也許你是通過將它看作一個靜態的鏈接網絡來簡化連通性的概念。當然，客戶需要知道資源中某些鏈接是否存在，但不一定需要確切知道遵循該鏈接的後果。

讓我嘗試一個舉例：用戶正在下訂單的一些項目，他們準備提交他們的購物車。提交鏈接實際上可能會根據訂單是在本地還是在國際上交付而轉到兩個不同的地方。也許訂單超過一定的價值需要經過一個額外的步驟。客戶只知道它必須遵循提交鏈接，但它沒有編譯知道下一步要去哪裏。當然你可以建立一個通用的「下一步」類型的資源，這樣客戶端可以明確地瞭解這些知識，但通過讓服務器動態地傳遞鏈接，你可以引入更少的客戶端 - 服務器耦合。

我認爲資源中的鏈接是佔位符，用戶可以選擇做什麼。誰來完成這項工作，以及它將如何完成取決於服務器連接到該鏈接的URI。

Answer 2

它更容易擴展，您可以編寫小應用程序和腳本，以便與核心應用程序一起工作。

補充：好的，整個觀點開始於你沒有在編譯時指定如何以硬編碼的方式將URI轉換爲uid的想法，相反，你可以使用字典或解析來做到這一點，給你一個很大的更靈活的系統。

然後後來說別人決定改變URI語法，那個人可以編寫一個小的腳本來翻譯URI，而不必接觸你的核心應用程序。另一個好處是，如果你的URI是邏輯上的其他用戶，即使是在公司場景中，也可以輕鬆地編寫Mash-ups來使用你的系統，而無需接觸你原來的應用程序，甚至不需要重新編譯它。

當然，整個論點的反面是，需要更長的時間才能通過簡單的UID系統實現基於URI的系統。但是，如果您的應用程序將被其他人以常規方式使用，那麼最初的時間投資將大大回報（可以說它具有良好的可擴展性ROI）。

補充：另一點是口味在一定程度母校是URI本身將是一個更好的名字，因爲它傳達了一個合乎邏輯的和定義的含義

Answer 3

我要添加自己的答案：

1. 要容易得多遵循比你自己構建它們的服務器提供的URI。由於資源關係變得太複雜而無法用簡單的規則來表達，因此尤其如此。在服務器中編寫邏輯比在衆多客戶端中重新實現它更容易。
2. 即使單個資源URI保持不變，資源之間的關係也可能會發生變化。例如，想象谷歌地圖將他們的地圖塊從0到100索引，從屏幕的左上角到右下角計算。如果Google地圖要更改其拼貼的比例，則計算相對拼貼索引的客戶端將會中斷。
3. 自定義ID標識資源。通過識別如何檢索資源表示，URI更進一步。這簡化了只讀客戶端的邏輯，如Web爬蟲或下載不透明資源（如視頻或音頻文件）的客戶端。