使用子列表作為查詢參數設計 REST 端點
[英]Design REST endpoint with sublist as query param
問題描述
我有一個 get 請求，它將根據輸入列表給我一個獲勝者。
例如）。 [{兔子：3，老虎：2}，{兔子：1，驢：3}，{鳥：2}]。 // 獲勝者是 {rabbit:1, donkey:3}
我想設計一個獲取列表的端點。
我能想到的一種方法是這樣的：
/GET 贏家？兔子，3？老虎，2&兔子，1？驢，3
請求參數映射會像 key:{rabbit,3?tiger,2}: value=[]
或者，我可以這樣做：
/GET 贏家?id1=rabbit,3?tiger,2&id2=rabbit,1?donkey,3
但我根本不需要身份證信息。
雖然這可以滿足我的需要，但我想知道用子對象表示查詢參數的最佳方式是什么？
2 個解決方案
解決方案1
0 2021-10-18 20:52:20
最明顯的似乎是：
GET /winner?rabbit=3&tiger=2&rabbit=1&donkey=3
解決方案2
0 2021-10-19 04:10:33
這里真的沒有很好的答案。
就 HTTP 而言，任何符合 RFC 3986 描述的生產規則的拼寫都可以。
如果您有一個可以通過URI Template輕松描述的表示，那么您（和您的客戶）可以利用通用模板庫。
但是...模板並沒有那么靈活，以至於它們可以用來描述任意消息模式。 我們得到了對字符串、（字符串的）列表和（字符串的）關聯數組的支持，而且……差不多就是這樣。
在 Web 上，我們可能會使用帶有 textarea 控件的表單來處理任意情況，該控件接受消息的字符串表示； 然后瀏覽器會創建一個鍵值對，其中的值是文本區域中信息的編碼表示。
因此，例如，您可以將 JSON 文檔的字符串表示復制到表單中，提交表單，瀏覽器將組成匹配的查詢部分。 在服務器上，您將反轉該過程以獲取 JSON 文檔。
當然，使用鍵值對並沒有什么特別神奇的地方。 另一種可能性是忽略鍵值的鍵，只使用正確編碼的值作為查詢。 同樣，服務器只是顛倒了這個過程。
另一種比較常見的嘗試是使用鍵值對，將鍵視為“路徑”——也就是說，每個鍵標識原始文檔中的一個位置，該值表示該位置可用的信息。
?/0/rabbit=1&/0/tiger=2&/1/rabbit=1&/1/donkey=3&/2/bird=2
在此示例中，鍵的架構基於 JSON 指針 (RFC 6901)，這是將分層數據扁平化為鍵值對的可能方法。 這可能不是“最好的”，但至少傾向於容易標准化的方向。 （標准化形式將是一種改進，但我無法確定一個）。
設計一個rest api，它使查詢參數大於某個值
聲明:本站的技術帖子網頁，遵循CC BY-SA 4.0協議，如果您需要轉載，請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.