在現實世界中使用Restful Web服務是否值得實現HATEOAS？

Question

如果我將現有的Restful Web服務轉換為盡可能的HATEOS，我一直在閱讀很多關於潛在好處的內容。 我理解在有效負載中提供鏈接的重要性，以減少消費者在記住下一個有效可用操作時的負擔。 但是，我似乎無法理解它將如何幫助我的Restful Web服務的消費者實際上。

為了說明這一點，我從“ 休息實踐”一書中摘取了關於制作咖啡訂單的例子： -

<order xmlns="http://schemas.restbucks.com">
  <location>takeAway</location>
  <item>
    <name>latte</name>
    <quantity>1</quantity>
    <milk>whole</milk>
    <size>small</size>
  </item>
  <cost>2.0</cost>
  <status>payment-expected</status>
  <link rel="payment" href="https://restbucks.com/payment/1234" />
</order>

基本上，這允許消費者進行由<link>標簽定義的支付。 然而，實際上，消費者仍然需要知道該Web服務調用的所有語義，例如，使用什么方法（POST或PUT），在有效載荷中使用哪些請求參數以進行支付等。換句話說，消費者仍然需要依賴WADL文檔來了解如何成功調用此Web服務。 如果他們都在一個特定項目上使用GET，這些標簽可能更有意義。 否則，我真的沒有看到在這里定義鏈接的好處...除了消費者知道他們接下來可以調用什么動作的事實，然后參考WADL來確定如何正確地調用它。

我的下一個問題是有可能以所有<link>標簽結束非常重的有效載荷。 例如，如果/ projects / 1 / users上的GET返回屬於項目1的所有用戶信息，我假設我最終會得到以下標記： -

<project>
    <users>
        <user id="12" name="mike" ... />
        <user id="23" name="kurt" ... />
        <user id="65" name="corey" ... />
    </user>
    <links>
        <link rel="self" href="http://server/projects/1/users"/>
        <link rel="create_user" href="http://server/projects/1/users"/>

        <link rel="get_user_mike" href="http://server/projects/1/users/12"/>
        <link rel="get_user_kurt" href="http://server/projects/1/users/23"/>
        <link rel="get_user_corey" href="http://server/projects/1/users/65"/>
        ...
    </links>
</project>

如果一個項目包含說，500個用戶......我不會在有效負載中有500個用戶鏈接嗎？ 否則，重新設計我的Web服務以處理這種情況的最佳方法是什么？ 或者這在現實世界中是否可以接受？

任何想法或建議在這里都非常感激。 謝謝。

Answer 1

想想為什么這是正確的做法，想象你的API沒有HATEOAS方法：你必須在你的文檔中（或在你的WADL，如果這是你的東西）發布每個可能的URI方案，並從那時開始如果不打破你的客戶，你就無法改變它們 。

從本質上講，您的客戶將與您選擇的URI布局密不可分。 這是一種耦合程度，您只需記錄鏈接在媒體類型中的位置，而不是記錄鏈接的外觀 ，即可輕松避免。

也就是說，您的應用程序可能需要采用這種方法，這很好。 請記住，您將長時間陷入URI布局。 不過你會很好 。

Answer 2

對於您的特定示例，我認為回歸HTML是有意義的。 如果您在HTML中顯示500個資源的列表，是否會包含指向每個資源的鏈接，以便用戶可以獲得更多信息？ 你可能會。 REST API沒有太大區別 - 如果返回500個資源的列表，則需要包含500個鏈接，以便用戶可以獲得有關每個資源的更多信息。

期望客戶基於某些ID或名稱構建URL就像要求用戶在瀏覽器的地址欄中手動鍵入URL。

這是一篇非常好的文章 ，特別是：

就像HTML文件通過標簽相互鏈接一樣，或者就像XML文件通過XLink鏈接到彼此一樣，所有狀態轉移都必須完全作為對表示內部鏈接的反應

Answer 3

只是關於500用戶事物的一個側面點：我不是專家，但我的理解是你可以安靜地提供分頁：

/項目/ 1 /用戶/頁/ 1

<links>
    ...
    <link rel="get_user_mike" href="http://server/projects/1/users/12"/>
    <link rel="get_user_kurt" href="http://server/projects/1/users/23"/>
    <link rel="get_user_corey" href="http://server/projects/1/users/65"/>
    <link rel="get_page_2" href="http://server/projects/1/users/pages/2"/>
</links>

Answer 4

這不是一個真正的答案，只是一些采用HATEOAS的技巧。 您不需要包含數百個鏈接，您可以包含指向500的完整列表的1個鏈接，指向鏈接的分頁子集的1個鏈接，或者在響應中包含分頁子集並添加下一頁鏈接。

為了響應WADL的事情，您應該使用內容設置，無論您的內容格式是什么，例如在HTML中， LINK和A元素表示客戶端應該發出GET請求，以及FORM元素用於POST請求。 顯然，其他格式和API XLink和XMLHTTPRequest比HTML支持HTTP更好。 您可以查看http://tools.ietf.org/html/draft-nottingham-link-hint