REST API，路徑變量vs請求參數

我目前正在編寫一個web服務，提供對某些資源的訪問。我試圖遵循REST，但是我正面臨有關API某些部分的問題。REST API，路徑變量vs請求參數

我有follwing的URI：

/爲MyService /用戶/：讓所有用戶
/爲MyService /用戶/ {用戶id}：獲得一個特定的用戶
/myservice /徽章/：獲取所有徽章
/myservice/badges/{badgeId}：獲取特定的ba dge

現在，我的問題是，我必須實現一種方式來獲取具有特定徽章的所有用戶。我可以認爲這僅僅是一個過濾器我申請的用戶列表中，因此以下URI：

/爲MyService /用戶/過濾器=徽章：{badgeId}

或者，我可以認爲這僅僅是一個徽章的子資源，因此以下URI：

/爲MyService /徽章/ {} badgeId /用戶/

哪一個看起來必須是'REST兼容'？

我必須說我已經閱讀了關於這個主題的一些帖子，特別是這一個：Rest Standard: Path parameters or Request parameters，但他們似乎並沒有掩蓋我的問題。

來源

2012-03-27 Guillaume D

REST對您的URI的外觀沒有任何意見。任何一個只是「符合REST」 – 2012-03-27 16:53:55

僅供參考，我對你提到的問題進行了一次嘗試，你可能對[回覆]（http://stackoverflow.com/a/31118242）感興趣。 – tne 2015-06-29 14:46:10

我更喜歡/myservice/users/?filter=badge:{badgeId}，我想更多的API使用這種格式。

來源

2012-03-27 16:33:48 abraham

如果您希望成爲RESTful，請考慮使用HATEOAS（可怕的首字母縮寫，但是確實是RESTful的關鍵）。

使用HATEOAS，你的徽章表示可能是這個樣子：

<badge> 
    <id>1234</id> 
    <name>Admin</name> 
    <link rel = "/rel/users" 
     href = "/myservice/users?badge=1234" /> 
    <link rel = "self" 
     href = "/myservice/badges/1234" /> 
</badge>

這使您的客戶端從服務器的URI方案脫鉤，因爲他們根本就什麼HREF的/相對/用戶的鏈接提供GET。授予您的服務器仍然需要在內部定義一個URI方案，但是如果您在某個時候決定不關心它，可以輕鬆更改它，而不會打斷您的客戶。例如，您可能希望你的URI方案改變你的第二個選擇，這將導致你的徽章代表來改變這樣的：使用/相對

<badge> 
    <id>1234</id> 
    <name>Admin</name> 
    <link rel = "/rel/users" 
     href = "/myservice/badges/1234/users" /> 
    <link rel = "self" 
     href = "/myservice/badges/1234" /> 
</badge>

客戶/用戶鏈接關係都不會受到URI更改。這可以歸結爲... 使用HATEOS，並且URI方案並不是真的很重要。

乾杯！

來源

2012-03-28 23:53:38 Andaris

REST API，路徑變量vs請求參數

回答

相關問題