REST風格：層次之間最佳的URI的設計和篩選

我有表日誌..和表裏面，我有一些列的，還有正在id_log，USER_ROLE，日誌，時間戳，定時器REST風格：層次之間最佳的URI的設計和篩選

USER_ROLE的類型是枚舉（ '客人'， '管理'， '主持人'）

我已經有2點的URI：

/logs (to represent all logs)

和

/logs/id-{number} (to represent logs with specific id_log)

我知道在URI設計中，/（斜線）用於表示與前一個分段有層次關係的資源..

用特定用戶角色表示日誌的最佳格式是什麼？

/logs/{role} (using role as hierarchy)

或

/logs?roll={role} (using role as filter)

請給我一個建議

來源

2013-09-23 stranger

'/ logs/{role}'和'/ logs？role = someValue'的作用相同。但是，對我而言，第二種方法似乎更合適。在REST中，我們討論資源。 – Joshi

@Joshi：感謝喬希..它現在是明確的：d – stranger

在REST中，你需要分離出資源和參數。在你的情況下，當你正確地聲明一個日誌並且標識一個實體時，資源應該構成URL的一部分。過濾日誌不是定義您正在獲取的資源的東西，所以應該是請求的參數。

考慮到你的表中還有一個timetstamp的事實。如果用戶想要通過時間戳和滾動來過濾特定的日誌，那麼如果您試圖將所有這些信息放入URL中，您最終會得到類似於/logs/{id}/{roll}/{timestamp}或/logs/{id}/{timestamp}/{roll}的內容，但是您已經在試圖構建自己的節點沒有明顯層次結構的規範URL。將它與/logs/{id}?roll=x&timestamp=y進行比較，您可以很清楚地知道您試圖獲取的內容（單個日誌）以及如何過濾它（通過滾動和時間戳）。這也允許您以各種方式更改查詢參數，例如roll參數可能爲!guest，而不會影響資源URL。順便說一下，它的作用不是滾動，而是堅持在上面的解釋中滾動以避免混淆。

來源

2013-09-23 09:41:44 jgm

呵呵呵呵..哦抱歉拼錯它..我的英語不好..呵呵呵呵感謝..所以現在的問題是明確的.. – stranger

REST風格：層次之間最佳的URI的設計和篩選

回答

相關問題