查询参数保留为 json [英] query parameter preserve as json

问题描述

我正在尝试以 JSON 格式存储 API 请求查询参数，以保留参数值的推断原始类型的方式.我在事先不知道这些 API 是什么样子的情况下执行此操作.下面的代码一一处理每个查询参数(由 & 分隔).

I'm trying to store API request query parameters in JSON format, in a way that preserves the inferred original types of the parameters' values. I do this without knowing what these APIs look like beforehand. The code below deals with each query argument (delimited by &) one by one.

    for (int i = 0; i < url_arg_cnt; i++) {
        const http_arg_t *arg = http_get_arg(http_info, i);
        if (cJSON_GetObjectItem(query, arg->name.p) == NULL) {
            // Currently just treating as a string.
            cJSON_AddItemToObject(query, arg->name.p, cJSON_CreateString(arg->value.p));
            SLOG_INFO("name:value is %s:%s\n", arg->name.p, arg->value.p);
        } else {
            //duplicate key.
        }

用上面的代码，用于输入

With the above code, for input

?start=0&count=2&format=policyid|second&id%5Bkey1%5D=1&id[key2]=2&object=%7Bone:1,two:2%7D&nested[][foo]=1&nested[][bar]=2

我得到了这些照片:

name:value is start:0
name:value is count:2
name:value is format:policyid|second
name:value is id[key1]:1
name:value is id[key2]:2
name:value is object:{one:1, two:2}
name:value is nested[][foo]:1
name:value is nested[][bar]:2

根据这份文件和我研究过的其他地方，https://swagger.io/docs/specification/serialization/

According to this document and other places I've researched, https://swagger.io/docs/specification/serialization/

对于如何传递查询参数没有达成共识，因此不能保证我在这里会遇到什么.所以我的目标是支持尽可能多的变体.这些可能性似乎是最常见的:

There is no consensus on how the query parameters are passed, therefore no guarantee what I could encounter here. So my goal is to support as many variations as possible. These possibilities seem to be the most common:

数组:

?x = 1,2,3

?x=1&x=2&x=3

?x=1%202%203

?x=1|2|3

?x[]=1&x[]=2

字符串:

?x=1

对象，可以嵌套:

?x[key1]=1&x[key2]=2

?x=%7Bkey1:1,key2:2%7D

?x[][foo]=1&x[][bar]=2

?fields[articles]=title,body&fields[people]=name

?x[0][foo]=bar&x[1][bar]=baz

任何想法如何最好地做到这一点?基本上对于这些查询参数，我想聚合(爆炸")属于一起的参数并保存到 query 适当的预期 json 对象.有问题的行:

Any ideas how to best go about this? Basically for these query parameters I want to aggregate ('exploded') arguments that belong together and save to query proper intended json objects. Line in question:

cJSON_AddItemToObject(query, arg->name.p, cJSON_CreateString(arg->value.p));

推荐答案

我最近遇到了同样的问题，将分享从这一集中获得的一些智慧.我假设您是在 MITM 设备(网络防火墙等)上实现的.正如问题中所指出的，在如何传递查询参数方面没有达成共识.没有一个标准或一组规则来管理这个——事实上，任何服务器都可以实现自己的语法，只要服务器代码支持该语法.最好的办法是 1) 决定支持哪些查询参数形式(尽你所能，也许尽可能多)和 2) 仅支持那些形式，将其余的(不支持的)视为字符串值，例如您当前的代码可以.

I recently ran into the same issue and will share some wisdom gained from the episode. I'm assuming you are implementing this on a MITM device (web firewall, etc.). As notedly in the question, there is no consensus in how the query parameters are passed. Not one standard or a set of rules that govern this -- in fact, any server may implement its own syntax, as long as the syntax is supported by the server code. The best one can do is to 1) decide what query parameter forms to support (do the best you can, maybe as many as possible) and 2) support only those forms, treat the rest (ones not supported) as String values, like your current code does.

过分担心所讨论类型的保存/推断的准确性，或将其形式化/概括为重量级解决方案是不值得的，因为 1) 您可能遇到的语法的任意性(不一定符合任何标准，Web 服务器真的可以做任何他们想做的事，因此查询参数通常不符合，比如说，引用的 swagger 标准)和 2)查看查询参数只会给你这么多信息——实施的好处/价值除了模糊的近似值(根据您自己定义的规则，如前所述)之外的任何东西都很难被看到.想想即使是最简单的情况，它们可能是多么模糊:你不得不假装在 x=something&x=something 爆炸的情况下，数组必须至少有两个元素.如果只有一个元素——x=something——你把它当作一个字符串，否则你怎么知道它是一个数组还是一个字符串?x=1 的情况如何，1 是字符串还是数字，原始/预期类型?另外，x=foo&y=1 怎么样?2 |3?或者当您看到带有空格的1,2,3"时?空格是否应该被忽略，它们是数组分隔符本身，还是它们实际上是数组元素的一部分.最后，你怎么知道想要的字符串不是 "1 |2 |3"本身，这意味着它不是数组！

It's not worth it to fret too much about the accuracy of the preservation/inference of type in question, or formalizing/generalizing it for a heavyweight solution because 1) the arbitrariness of syntax you may encounter (not necessarily conforming to any standard, web servers can really do whatever they want, therefore the query parameters often don't conform to the, say, swagger standard referenced) and 2) looking at the query parameters only gives you so much information -- the benefit/value of implementing anything more than vague approximations (per rules defined by yourself, as stated before) is hard to be seen. Think about even the simplest of cases, how vague they can be: you sorta have to pretend in the x=something&x=something exploded case, arrays have to have at least two elements. If only one element -- x=something -- you treat it as a string, for how else do you know whether it's an array or a string? How about the x=1 case, is 1 a string or a number, the original / intended type? Also, how about x=foo&y=1 | 2 | 3? or when you see "1, 2, 3", with spaces? Are the spaces supposed to be ignored, are they array delimiters themselves, or are they actually a part of the array elements. Finally, how do you even know the intended string is not "1 | 2 | 3" itself, meaning it's not an array!

因此，在解析这些字符串并尝试支持/推断所有这些变体(不同的规则)时，最好的做法是定义自己的规则(可以/满意的规则)并仅支持这些规则.

So the best one can do in parsing these strings and trying to support/ infer all these variations (different rules) is to define ones own rules (what one is okay/happy with) and support only those.

这篇关于查询参数保留为 json的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！