设计携带嵌套对象列表为查询参数的REST GET端点的最佳方案

你提到的两种现有方案都存在合规性或可维护性问题，不推荐使用：

• 第一种无key=value结构的参数写法完全不符合HTTP查询参数标准规范，大部分反向代理、服务端框架会解析失败，可靠性极差。
• 第二种用无意义id作为参数键的写法虽然可以运行，但语义性差，后续扩展参数结构的成本很高。

行业通用的合规实现方案有三种，可根据你的实际场景选择：

方案1：JSON序列化单参数传递（最省事通用） #

直接将整个输入列表序列化为JSON字符串，URL编码后作为单个查询参数的值传递，示例请求如下：

GET /winner?input=%5B%7B%22rabbit%22%3A3%2C%22tiger%22%3A2%7D%2C%7B%22rabbit%22%3A1%2C%22donkey%22%3A3%7D%2C%7B%22bird%22%3A2%7D%5D

优点：无需自定义解析规则，所有服务端语言都有现成的JSON反序列化能力，支持任意复杂度的参数结构，扩展成本为0。
缺点：参数可读性较低，调试时需要做URL解码+JSON格式化，大体积输入可能触发URL长度限制。

方案2：框架原生支持的嵌套参数写法（最规范语义化） #

主流服务端框架（Spring、Express、Django等）都原生支持数组名[索引].对象键=值的嵌套参数格式，可直接解析为对应结构的对象数组，示例请求如下：

GET /winner?items[0].rabbit=3&items[0].tiger=2&items[1].rabbit=1&items[1].donkey=3&items[2].bird=2

优点：参数语义清晰，不需要额外写解析逻辑，完全符合REST API设计规范，后续扩展字段非常方便。
缺点：输入数组较长时URL长度会偏大，常规场景下完全够用，超大输入建议改用POST请求传递body。

方案3：简化分隔符写法（适合固定简单结构） #

如果你的每个子对象固定只有一个「动物:分数」的键值对，可以用同键多值的数组传递方式，每个数组元素内部用分隔符拆分内容，示例请求如下：

GET /winner?items=rabbit:3,tiger:2&items=rabbit:1,donkey:3&items=bird:2

优点：参数简洁，解析逻辑简单，URL长度较短。
缺点：仅适合固定的简单结构，扩展能力差。

选型建议 #

• 后续可能扩展参数结构选方案2
• 想最小成本实现选方案1
• 结构固定且追求URL简洁选方案3

内容的提问来源于stack exchange，提问作者AmILostYet