消費從資源ID

Question

讓我們考慮下面的流向問題的REST API一個REST API端點：

API root  
     | 
     v 
    user list  
     | 
     v 
    user details 
     | 
     v 
    user messages 

假設我有一個客戶端使用的API，我想從ID的用戶檢索郵件42. 從我一直在研究中，我的客戶不應該知道如何「建立」網址，它應該遵循API給出的鏈接。

我該如何檢索ID爲42的用戶的郵件？

我能想到的唯一方法就是將整個API從它的根節點「移動」到用戶消息，這對我來說看起來並不漂亮或高效。

例如：
1 - GET /和獲取鏈接到用戶
2的列表 - GET /用戶/ ID = 42和獲取鏈接到與該ID的用戶的細節42
3 - ？ GET/user/42 /並獲得鏈接到用戶42消息列表
4 - GET/user/42/messages /並最終獲得用戶消息

我有什麼問題嗎？根據Roy的菲爾丁論文，這是否正確？ 或者可以假設消息url是「/ user/{id}/messages /」並直接發出請求嗎？

Answer 1

我相信你真正關心的是你應該去執行HATEOAS還是不行。現在，由於它是REST規範的組成部分，因此建議每個實體都應該鏈接到它包含的子實體。在你的情況下，API ROOT應該顯示具有鏈接（/ root/users/{id}）的每個「用戶」到相應用戶的詳細信息的用戶列表。每個用戶詳細信息實體都將包含指向「消息」列表（/ root/users/{id}/messages）的鏈接，最後，它還包含實際消息詳細信息的鏈接（/ root/users/{ ID} /消息/ {MESSAGEID}）。這個概念非常有用（因此也是規範的一部分），因爲客戶端不需要知道實體所在的URL。例如，如果您的用戶位於http://users.abc.com/rest/users/ {id}，但您的郵件位於http://messages.abc.com/rest/ {userId}/messages/{messageId}，則包含「郵件」列表的用戶實體將已經嵌入鏈接以指向正確的資源在不同的服務器上。現在說的是，在HATEOAS廣泛使用的地方，我並沒有看到許多REST實現（我必須承認我沒有太多的經驗，但足以表達觀點）。在大多數情況下，資源幾乎總是在同一個服務器（環境）上，而資源的路徑幾乎總是相對於根url。因此，當客戶端從對象中解析出嵌入式鏈接時沒有任何意義它們可以自己生成一個，特別是當客戶端想要直接提供對資源的訪問時（直接查看消息而不提供用戶實體，因爲您已經知道messageId是什麼）。最後，這一切都取決於你希望你的REST實現與規範的距離有多近，以及你將擁有哪種類型的客戶端。我的2美分將是：如果你有時間，用HATEOAS實施REST併爲此感到自豪:)。有一些庫會讓這個實現（HATEOAS）對你的REST實現有些透明（我相信spring有一個，儘管不是很成熟，你可以看看它here）。如果你和我一樣，也沒有太多時間走這條路線，我認爲你可以在沒有HATEOAS的情況下繼續正常的REST實現，並且你的客戶仍然可以使用它（或者我希望！）

Hope這有助於！

Answer 2

在您的API根目錄中使用URL模板。讓客戶端在運行時使用API​​根。它應該查找名爲「user-messages」的URL模板，其值爲「/ user/{userid}/messages /」。然後讓客戶端在模板中將「{userid}」替換爲「42」，然後對生成的URL執行GET。您可以爲所有必需的，經常使用的用例添加儘可能多的這些URL模板。

此解決方案與「經典」Web API的區別在於URL的後期綁定：客戶端在運行時讀取API根與其模板 - 而不是使用URL模板的知識編譯客戶端。

看看HAL的媒體類型有關URL模板的一些信息：http://stateless.co/hal_specification.html

我前段時間寫了這塊這裏解釋一下超媒體的好處：http://soabits.blogspot.dk/2013/12/selling-benefits-of-hypermedia.html

Answer 3

我發現這篇文章關於黑客網址：Avoid hackable URLs。
在評論部分有一個關於這個問題主題的非常有趣的討論。