它是否符合HATEOAS？獲取具有不同結果的相同地址

當此調用每次返回不同的資源時，它是否符合HATEOAS要求通過GET /resources公開資源？例如，根據某些內部算法在客戶端之間分配資源，這意味着我不希望每個客戶端都總是收到相同的資源（假設我編寫了「當天的短語」服務器並隨機分配它們）：它是否符合HATEOAS？獲取具有不同結果的相同地址

第一次調用：GET /資源

200 OK 
{ 
    "_links" : { "self" : "/resources/1" }, 
    "data" : "foo" 
}

第二個電話：GET /資源

200 OK 
{ 
    "_links" : { "self" : "/resources/2" }, 
    "data" : "bar" 
}

還是更提供GET /resources/chooser返回links對象到具體資源並進行第二次調用？

來源

2014-12-02 Pedro Montoto García

GET應該是冪等的 - 請參閱https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods – Squidly 2014-12-02 14:52:29

根據您的鏈接「冪等是指請求完成後系統的狀態，因此，服務器需要（例如刪除一條記錄），或者它返回的響應代碼在後續請求中可能會有所不同「 – 2014-12-02 14:54:52

您誤解了它 - 指的是'PUT'＆'DELETE'。'GET'請求'不應該有副作用，除了相對無害的影響，如日誌記錄，緩存，橫幅廣告的投放或增加web計數器。'這裏的網站櫃檯是跟蹤訪客數量的東西。 – Squidly 2014-12-02 15:02:16

HATEOAS是關於以下鏈接。因此，除非您將這些操作（除了獲取API根）暴露爲元數據的鏈接（例如您的示例中的「self」），否則它將滿足HATEOAS約束條件。關於URI結構沒有標準，只是建議。例如，爲命名資源路由呼叫比較容易。請注意，對於REST客戶端，URI結構並不重要，因爲它會檢查鏈接元數據以決定是否要遵循鏈接。

在你當前的例子中，/resources應該有一個自我描述性的元數據，例如rel=chooser或類似的東西。所以客戶會知道它是什麼。我認爲您的URI結構違反了URI標準，因爲路徑描述了URI的分層部分，但在當前情況下，在/resources和/resources/1,/resources/2 URI之間沒有層次結構。所以，如果你想創建和別名或選擇「選擇器」的話，使用/resources/chooser或/resources?chooser=true要好得多。

來源

2014-12-02 15:14:19 inf3rno

有一個[RFC for URI Templating]（https://tools.ietf.org/html/rfc6570） – renatoargh 2014-12-02 15:24:06

@renatoargh是的，有，但它與URI結構無關。例如。 'resources/adsfgf432342'，'cars/3546473'，'cars？id = 3546473'可以表示完全相同的東西。您可以使用URI模板來描述結構模板。 – inf3rno 2014-12-02 15:26:15

同意。至少它是閱讀的起點！ :) – renatoargh 2014-12-02 15:28:37

要回答您的直接問題，假設/ resource是您的應用程序的入口點，或者您有一個鏈接到/ resource的根資源，它肯定符合HATEOAS約束。

問如果這是RESTful體系結構還是有點棘手。有一件事是你必須絕對錶明結果不可緩存。使用HTTP這將是一個HTTP頭。這是假設每個/資源請求會得到一個新的資源...也許同一個用戶獲得相同的資源..你可以允許緩存。

我一直對GET的idempotence感到困惑。您可以使用GET進行良好的搜索，如果它們更新了相同的GET，則可能會改變結果。當然，這是改變國家的其他東西......但我記得讀到他們會根據結果的點擊率改變排名..這也是一個GET ...所以??

如果它是我的API，並且僅僅發出POST請求並不是什麼大事，那麼我可能會使用POST和406一個GET。如果我真的需要GET，我不會太擔心。

來源

2014-12-02 21:48:15

它是否符合HATEOAS？獲取具有不同結果的相同地址

回答

相關問題