如果我有一個資源/用戶和資源/索賠，這樣/索賠/ 7的回報是：什麼時候應該在響應正文中包含URI？
{ id: 7, text: "hello", postingUserID: 9 }
是好嗎？還是應
{ id: 7, text: "hello", postingUserURI: "https://stackoverflow.com/users/9" }
我想像後者是更舒適的，但它是不方便的，因爲當時我要解析出9，如果我想要做別的用的ID。
也許我應該兼得？
{ id: 7, text: "hello", postingUserID: 9, postingUserURI: "https://stackoverflow.com/users/9" }
我喜歡這個，但它也有點多餘。
什麼是最寧靜的事是什麼？謝謝！
最RESTful的事情做的是包括URI。第一個選項對於RESTful客戶端來說並不是很有用，因爲它代表了一個死衚衕。 Web瀏覽器是一個很好的客戶端示例：選項1就像提供沒有超鏈接的網頁一樣。用戶無法前進應用程序狀態（瀏覽器選項卡），他們只能閱讀頁面，然後按下「後退」按鈕。
我會推薦選項2.客戶端不應該需要任何ID，因爲它們只能用於諸如使用URI模板生成的RPC樣式的HTTP請求。這代表不是REST的帶外信息。 ID是不需要公開的內部實現細節。您甚至不需要包含索賠對象的ID。您目前在客戶端使用的任何ID都應該使用從前一個請求收到的超鏈接。
舉個例子，我自己的API有一個「作業號」，這個數字是沒有字母部分的整數。我在數據庫中使用自動遞增的ID字段來生成並保存這些作業號，但是當它們呈現給客戶端時，我將其作爲「作業號」而不是數據庫ID。客戶不會將此用於生成任何未來請求，只能用於人類可讀的顯示。
當開發一個新的API，你可能會發現它很有用輸出HTML頁面，看起來像你的JSON響應。然後使用Web瀏覽器瀏覽它。每個GET請求都應該通過單擊超鏈接（錨點元素）而不是通過在URL欄中輸入ID來生成。這項技術被稱爲API衝浪。
與REST無關，我會將postingUserURI更改爲author作爲URI的字段名稱。
我並沒有參與這個問題的結束，而是要把它重新開放，我建議而不是問「其中這些是最好的」類型的問題，它可能是更好的詞爲「我正在考慮這些選項適合這個計劃......它們各自適合嗎？如果不是，請解釋爲什麼我選擇它之前。「這樣你就不會徵求意見，而是要求事實。您將選擇留給自己，並可能會收到相同的答案。 –
聽起來不錯，thx – Verdagon