我有一个获取请求，它将根据输入列表给我一个获胜者。
例如）。[{兔子：3，老虎：2}，{兔子：1，驴：3}，{鸟：2}]。// 获胜者是 {rabbit:1, donkey:3}
我想设计一个获取列表的端点。
我能想到的一种方法是这样的：
/GET Winner?rabbit,3?tiger,2&rabbit,1?donkey,3
请求参数映射像 key:{rabbit,3?tiger,2}: value=[]
或者，我可以这样做：
/GET 获胜者?id1=兔子,3?老虎,2&id2=兔子,1?驴,3
但我根本不需要身份证信息。
虽然这可以满足我的需要，但我想知道用子对象表示查询参数的最佳方式是什么？
这里真的没有很好的答案。
就 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)，这是将分层数据扁平化为键值对的可能方式。这可能不是“最好的”，但至少倾向于易于标准化的方向。（标准化表格会是一种改进，但我无法确定一个）。
最明显的似乎是：
GET /winner?rabbit=3&tiger=2&rabbit=1&donkey=3