我目前正在使用PHP設計和實現RESTful API。 該API允許用戶搜索酒店。如何在REST API搜索查詢中返回過濾元數據
搜索請求的一個簡化的例子是:
GET hotels/searchresults?location=<location> #collection of hotels within location
響應還包含有關返回的集合一些元信息。 響應的基本結構是:
「meta": {
「totalNrOfHotels": 100,
"totalNrAvailable": 80
},
「hotels": [
{
「id": 123,
「name": "Hotel A"
},
{
「id": 135,
「name": "Hotel B"
},
...
]
該資源還支持分頁:
GET hotels/searchresults?location=<location>&offset=0&limit=20
現在,有可被應用於搜索結果的一些過濾器,例如星星,評分。 例如,如果我想只是2家星級酒店,我可以查詢:現在
GET hotels/searchresults?location=<location>&offset=0&limit=20&stars=2
,在用戶界面中的過濾,通常顯示的每個過濾器設置可選項的數量:
在我看來,這些數字可以看作是有關搜索查詢的元數據。所以,我們可以在響應一個額外的字段添加到元:
「meta": {
「totalNrOfHotels": 100,
"totalNrAvailable": 80
「filterNrs": {
"stars」: {
「1": 1,
「2」: 9,
「3」: 39,
「4」: 12,
「5」: 11,
「none」: 9
}
}
},
「hotels": [
{「id": 123,
「name": "Hotel A"
},
{「id": 135,
「name": "Hotel B"
},
...
]
所以,我有兩個問題:
應該提出這個「filterNrs」屬性靜坐在元部分,以上?對我來說,將它作爲一個單獨的資源/請求是沒有意義的
我們該如何處理這樣會降低查詢速度的事實?我寧願使「filterNrs」字段可選。我們正在考慮使用「metaFields」參數來允許用戶指定她想要接收的元數據中的哪些字段。我們已經爲返回的酒店支持這個參數,並帶有「fields」參數(類似於:https://developers.google.com/youtube/2.0/developers_guide_protocol_partial)。或者,我們把這個字段filterNrs(或完整的元信息)放在一個單獨的資源中,比如
hotels/searchresults/meta
。從開發人員的角度來看,你更喜歡將這個分割成多個資源,或者讓一個資源具有顯示全部或部分元信息?