集合類的REST風格的URL？

我正在實施一個web應用程序，並希望遵守RESTfull設計標準，我的問題是。集合類的REST風格的URL？

給定一個集合的類。

人{ ID ::整數名:: string的朋友::收藏者的}

會是什麼 '最' 正確的方式來實現與人類的接口：

example.com/REST/persons -> [... {id: '2', name: 'Pete', friends: [1,4,6]} ... ] 
example.com/REST/persons/2 -> {id: '2', name: 'Pete', friends: [1,4,6]}

通過在人員類上使用某種搜索功能來查找朋友的位置？

或

example.com/REST/persons -> [... {id: '2', name: 'Pete'} ... ] 
example.com/REST/persons/2 -> {id: '2', name: 'Pete'} 
example.com/REST/persons/2/friends -> [{id: '1', name: 'Joann'}, 
             {id: '4', name: 'Jim'}, 
             {id: '6', name: 'Charlie'}]

凡集合中的元素都擡頭看着我，在人的實例字段。

我已經看到兩件事情都實現了，但我想遵守standarts。

一條生路只是被我吞噬了。

example.com/REST/persons/2 -> {id  : '2', 
           name : 'Pete', 
           friends: [example.com/REST/person/1, 
             example.com/REST/person/4, 
             example.com/REST/person/6]}

從而使得界面事件的更多問題的REST - 客戶端現在可以遍歷整個界面在不知道具體實現。

我希望有一些輸入在那裏。

來源

2013-02-05 Martin Kristiansen

你打算用什麼技術來實現你的REST API？這個選擇可以爲你做出這個決定。 –

此外，您的問題標題有誤導性，看起來您正在尋找網址格式，而不是實際的實施。 – Zepplock

@Zepplock：我改變了標題 –

擁有example.com/REST/persons/{person-id}/friends/{friends-id}是一種正確的方法。 REST本身不強制執行任何URL組合規則，但大多數人都這樣做。

基本上你有一個資源Person和子資源Friend與多對多的關係。

來源

2013-02-05 17:40:21 Zepplock

那朋友，朋友呢？不是因爲一個非常不潔和長的界面嗎？ –

那麼這個想法是，用這個URL你可以很容易地看到關係。對於每個'''人'''你可以得到一個朋友列表。沒有必要將這些資源鏈接到兩級以上。 – Zepplock

其他人只是告訴我，正確的方法可能是在頂級對象中提供url列表......因此更容易獲得資源RESTfull –

集合類的REST風格的URL？

回答

相關問題