你如何避免固定資源

Question

Roy Fielding writes

一個REST API一定不能定義固定 資源名稱或層次結構（客戶端和服務器 的 明顯的耦合）。服務器必須有自由 來控制自己的名字空間。 相反，允許服務器指示如何構建 相應的URI 客戶，如在 HTML表單和URI模板完成後，由 定義內 媒體類型和鏈接關係的說明。

你如何做到這一點系統到系統接口？假設客戶想要在服務器上創建一個訂單http://my.server.org它應該如何知道創建訂單時應該使用網址http://my.server.org/newOrder而不是http://my.server.org/nO或其他任何東西？

對於人機界面（即瀏覽器），我猜服務器會提供某種形式的鏈接（可能在form元素中），並且該鏈接中的文本會告訴用戶該頁面上的哪些表單是正確的一個用於創建訂單（應該是創建用戶或導航到某個搜索結果）

用於在客戶端實現此操作的機制是什麼？還有：他們實際上是使用了還是大多數人只是把這些網址連接到客戶端？

Answer 1

你如何做到這一點 系統到系統的接口？說 客戶想在http://my.server.org創建於 服務器的順序如何 它應該瞭解到，用於創建 它應該使用的URL訂單 http://my.server.org/newOrder，而不是 http://my.server.org/nO或任何其他 ？

它不學習。機器客戶通常不能「學習」。至少還沒有，我們還在天網之前。你必須「教」他們。

但關鍵是你不教他們的網址。你教他們的關係。

請考慮，在HTML中...

<a rel="order" href="http://my.server.org/newOrder"/> 

和

<a rel="order" href="http://my.server.org/nO"/> 

你會發現，相對是一樣的， 「訂單」，但網址並非如此。

在一個「完美」的世界裏，你的系統將有一個入口點，比如http://my.server.org/，從那裏客戶可以找到它需要知道的所有資源。

實際上，許多系統都有幾個「衆所周知的」，並且定義了入口點，客戶端可以從這些入口點開始，這只是一種權宜之計，所以客戶端並不必須從系統的根部開始。這些衆所周知的入口點暗示了供應商的承諾，即這些URL不會很快改變。他們已經很久了，服務器會很好地支持他們。

但是一旦通過入口點，您發現的任何URL都可能沒有這樣的承諾。該網址可以是隻能使用一個網址的網址。它可以針對不同的機器進行負載平衡。誰知道。但作爲服務的消費者，你真的不關心網址是什麼，你只關心關係。關係告訴你要使用的URL的詳細信息。

您的超媒體API文檔解釋瞭如何將統一界面應用到您的客戶將遇到的每個rels。客戶不能「直覺」，要麼教它。

基本上，通過教導客戶端如何瀏覽它會或可能在負載中找到的關係，它處理的是客戶端如何操作超媒體API。有效載荷包含標誌帖子以顯示方式，但服務器指定這些標誌帖子的位置。

至於多久使用它，在機器到機器的世界裏，可能不是很多。大多數系統的URL不夠大，URL變化不夠重要，客戶數量太少，以至於更換客戶端並不是一項重大負擔。所以大部分只是硬編碼。

但是，最後，你只是有壞客戶。一個REST系統可以用壞客戶端做什麼。無論如何，它無法在運行時將它們分開。

Answer 2

無論您如何發佈API（要被機器使用），都有可能做出重大改變。當您將API包裝到UI（如HTML表單）後面時，您可以自由更改URI而不會中斷用戶，但這是因爲用戶正在使用您提供的抽象。在不更改表單的情況下更改URL架構，並且仍會破壞客戶端。

幾種方法，以避免破壞機客戶端（基本上，支持向後兼容）：在某種URL版本的

• 構建
從舊的URL模式
• 待辦事項重定向到新的架構

Answer 3

我們已經非常成功地以如下方式接近它：在應用程序的根URL上公開WADL文件，描述媒體類型以及在其中查找鏈接的位置及其語義。我知道這個（WADL）在REST社區中被某些人認爲是非常重要的，但我總是隻被WADL的URL焦點所嚇倒。除了所有的宗教辯論之外，我們喜歡有一個明確的文件表述方式。有一種方法可以避開WADL的URL焦點，而是指出可以在表示中找到哪些鏈接，然後將其記錄下來。有關該方法的詳細信息，請參閱that blog post（由於維護原因，因此您可能需要查看Google cache）。

這會導致客戶端只能找到一個URL，因爲他可以找到有關它訪問WADL的信息，從此只需瞭解表示形式以及在哪裏可以找到鏈接，什麼HTTP方法需要什麼參數被調用等。