鏈接擴展關係類型URI在RESTful API中應該指向什麼？

我一直在設計一個最近需要RESTful的API，並且已經設法定義一個系統，該系統專門使用HTTP頭和查詢字符串參數來定義元數據，以便響應體可以是實際的資源數據只要。鏈接擴展關係類型URI在RESTful API中應該指向什麼？

但是我現在考慮的是HATEOAS的鏈接，並且由於希望將所有內容保留在HTTP標頭或查詢字符串參數中，所以我決定使用HTTP Link標頭字段。

這提出了一個關於rel屬性的問題，我無法找到直接的答案。

我的想法是對資源的集合，將在響應中發送的Link S的人會是這樣的：Link: <https://api.domain.com/things/{id}>; rel="..."

這將允許客戶端使用簡單的字符串擴展，在RFC6570定義，爲集合中的每個資源創建正確的資源URI，而無需將元數據嵌入到每個資源中，而且除了URI模板和資源ID之外，客戶端不需要知道任何內容。

但是，我不確定rel應該在這裏，或它應該指向什麼。

在RFC5988，它說的是，延伸的關係類型必須是一個URI和：

雖然URI可以指向包含關係類型的語義，客戶應的定義的資源不自動訪問該資源以避免使其服務器負擔過重。

我的問題是，RESTful API中的定義應該是什麼樣子？

通過它的外觀，我可以讓rel類似https://api.domain.com/media/thing，或類似的東西。

但是那麼實際的定義內容應該是什麼？

看起來它在技術上可以是任何東西，例如一個帶簡短說明的純文本文檔。

這些類型的rel屬性是否有任何RESTful標準以及它們應該指向什麼？

任何幫助表示讚賞。

來源

2016-11-11 Jake Lucas

看着Richardson's Maturity Model 3級，rel似乎代表發佈的鏈接/關係的名稱。例如，在您的情況下，可能會轉換爲curie:thing-by-id（假設您使用建議的HAL draft中建議的居里）。這個想法是，客戶可以通過其名稱（rel）搜索鏈接，而無需查看實際的url。

來源

2016-11-11 08:00:05

因此，看起來HAL草案提供了一個很好的建議，即rel URI應該指向一個包含關係文檔的HTML頁面，而CURIE將用於減少數據傳輸大小，併爲客戶端提供一致的密鑰以查找爲該關係檢索href，即使rel URI本身發生變化。基本上，使用rel指向HTML文檔，使用CURIE使用rel作爲href查找，因爲key更可靠。是嗎？如果我理解正確，那麼我認爲這很好地回答了我的問題，但我會等待確認。 –

是的，這幾乎是我對它的理解， –

感謝您的澄清:) –

鏈接擴展關係類型URI在RESTful API中應該指向什麼？

回答

相關問題