使用子列表作为查询参数设计 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.