http rest：在查询字符串中使用 json 的缺点？答案

【问题标题】：http rest: Disadvantages of using json in query string?http rest：在查询字符串中使用 json 的缺点？
【发布时间】：2016-11-21 08:54:55
【问题描述】：

我想使用查询字符串作为 json，例如：/api/uri?{"key":"value"}，而不是 /api/uri?key=value。在我看来，优点是：

json 保留参数类型，例如布尔值、整数、浮点数和字符串。标准查询字符串将所有参数视为字符串。
json对于深层嵌套结构的符号较少，例如?{"a":{"b":{"c":[1,2,3]}}} vs ?a[b][c][]=1&a[b][c][]=2&a[b][c][]=3
更容易在客户端构建

在这种情况下使用 json 会有什么缺点？

【问题讨论】：

网址可能会过长。
您可能对此感兴趣：softwareengineering.stackexchange.com/questions/270898/… 基本思想是，在基于 REST 的 API 中，资源应尽可能干净地映射到 URI。我认为将 JSON 放入查询字符串中恰恰相反。

【解决方案1】：

如果它看起来不错

/api/uri?{"key":"value"}

如您的示例中所述，但由于它是 URL 的一部分，因此它被编码为：

/api/uri?%3F%7B%22key%22%3A%22value%22%7D

或类似的东西使/api/uri?key=value 比编码的更简单；在这种情况下，用于调试出站呼叫（即您想通过wireshark等检查实际请求）。另请注意，编码为有效 url 时会占用更多字符（请参阅浏览器限制）。

对于“嵌套结构的较小符号”的情况，为您的子资源创建一个新资源可能更合适，您将在其中通过查询参数处理过滤；

api/a?{"b":1,}

到

api/b?bfield1=1
api/a?aBfield1=1 // or something similar

最后，为了“更容易在客户端构建”，我认为这取决于您用于创建客户端的内容，通常查询参数表示为地图，所以它仍然很简单。

另外，如果您需要单个参数的集合，那么：

/uri/resource?param1=value1,value2,value3

【讨论】：

但是[ 和] 也被转义了，所以?a[b][c][]=1&a[b][c][]=2&a[b][c][]=3 变成了a%5Bb%5D%5Bc%5D%5B%5D=1&a%5Bb%5D%5Bc%5D%5B%5D=2&a%5Bb%5D%5Bc%5D%5B%5D=3，所以，这两个变体都是不可读的。
在什么特殊情况下需要括号？如果您的资源需要一个集合作为参数不是由/api/uri?param=value1,value2,value3 表示的？
当然，只有一个集合可以用这种语法表示。但是，例如，有一个问题，如果 param 需要包含“，”符号，那么应该有一些转义。括号需要定义嵌套结构，不是列表，也不是结构列表。但是json的主要优点是对最终用户来说很简单：你没有N条规则，一个用于集合，一个用于结构，自定义转义等。只需json_encode或JSON.stringify你的php数组/js对象并将其传递为请求参数。简单明了。
正如我在原始示例中提到的，嵌套结构将作为不同的资源处理。如果您的参数需要,，那么这就是转义字符发挥作用的地方。如果您想要一个格式精美的 json，那么我建议将其更改为 POST 并使其成为有效负载（如 elasticsearch）。只是我的 2 美分 :)
不可能将复杂查询作为嵌套资源处理。例如，我想实现模式匹配列表过滤。因此，我将结构作为对资源的查询传递，它返回实体列表。查询结构描述结果实体的形状。我可以找出嵌套资源如何适合这种情况。