2
設計REST API時,傳遞用於統計和日誌記錄所需的元數據但不會更改服務器響應的最佳做法是什麼?RESTful API設計請求元數據(會話ID等)的最佳實踐?
例如,如果我有服務查找最近的公共廁所,我可能想知道用戶的位置是否由GPS確定。或者,如果最終用戶的請求經過多個系統,我可能想要傳遞一個請求ID以進行調試。
據我瞭解的選項有:
查詢參數
- 喜歡上了谷歌地圖API的「傳感器」參數。
- 沒錯,因爲它可以讓用戶使用普通的網頁瀏覽器來瀏覽API。
- 對,因爲對於發現很難發送自定義HTTP標頭的客戶來說更簡單。
- 錯誤,因爲篩選參數僅用於過濾,排序&搜索。
- 錯誤,因爲如果資源沒有改變,爲什麼要這個URL?
HTTP頭
- 比如認證往往是做
- 正確的,因爲它是請求元數據的正常位置不改變服務器的響應
- 正確的,因爲,對於POST/PUT請求,它避免了同時具有查詢參數和請求主體。
- 錯誤,因爲當您使用Web瀏覽器瀏覽API時無法設置標題。
- 錯誤,因爲應避免複雜性,並且URL +標頭比單獨的URL更復雜。
如果允許元數據不存在,那麼這是正確的選擇?
如果元數據必須存在,答案會不同,儘管它的值不會改變服務器的響應嗎?