url使用SetQuery方法时，value为空，请求会去除当前key
canfeng11 opened this issue · comments
query := gout.H{
"t": 1296,
"callback": "searchresult",
"q": "美食",
"stype": 1,
"pagesize": 100,
"pagenum": 1,
"imageType": 2,
"imageColor": "",
"brand": "",
"imageSType": "",
"fr": 1,
"sortFlag": 1,
"imageUType": "",
"btype": "",
"authid": "",
"_": 1611822443760,
}
调用代码如下：
gout.GET(url).Debug(true).SetQuery(query).SetHeader(header).BindBody(&body).Do()
控制台请求信息如下：
> GET xxxx?_=1611822443760&callback=searchresult&fr=1&imageType=2&pagenum=1&pagesize=100&q=%E7%BE%8E%E9%A3%9F&sortFlag=1&stype=1&t=1296 HTTP/1.1
发现：当value为空时，请求的query会自动删除key值
是的，目前是这么设计的。服务端现在用的什么框架取数据？
这个和服务端没啥关系吧，如果我有些时候就是需要传空的话，这样设计就很不合理啊，因为有些字段是必须字段，不能不传
了解。所以你的预期是，假如值为空，也需要生成key值？
正常的逻辑不应该是这样吗？这个逻辑应该是key值为空才过滤吧
新加个api，不过滤空值。你看下函数名有没有可以优化的地方NotIgnoreEmpty()。
gout.GET(url).NotIgnoreEmpty().Debug(true).SetQuery(query).SetHeader(header).BindBody(&body).Do()或者CanEmpty()
我感觉你应该反着思维吧，正常的应该不过滤，然后你加个函数可以过滤，这样才符合正常使用思维
这样会影响现有逻辑，出现不兼容修改。举例来说。以前是gout.H有值才生成url字符串。反着来语义就不一样了，不管有没有值，都生成url字符串。因为不能同步到所有用这个库的人，所以更倾向于兼容式修改。
换种思维方式嘛，你不是做了一个方法取消空值的方法嘛，那么你再底层默认调用，当用户调用其他其他函数增加这个限制，底层就不调用，这样不就解决了
抱歉，不是太明白，你的意思是加SetQueryCanEmpty()这样的接口，通过新的API规避以前的逻辑，是吧。
满足你说的如下的意思。
“
当用户调用其他其他函数增加这个限制
”
我的初步想法，先加CanEmpty满足你功能上面的需求。
只不过加了一个新的函数，如果觉得写起来没有一开始爽。我后面教你如何包装第三方库的方法，写很少量的code，打造最适合你习惯的http client.
你权衡下，如果没问题，pr会在这两天做完。
我的意思是：
1、正常逻辑就是不去掉value为空的值，解决办法就是，你写个方法NotIgnoreEmpty()，但是默认是自动调用的，这样就可以解决我的问题；
2、当用户真的是需要去掉value为空的时候，当然我觉得这种情况非常少，因为去掉我直接不写不就可以了嘛！干嘛还要你去掉！当用户处于这种情况的时候，你提供一个方法，供用户显性调用；
gout.GET(url).IgnoreEmpty().Debug(true).SetQuery(query).SetHeader(header).BindBody(&body).Do()
3、我觉得更多的是key值为空，这种情况是真的不应该传参，因为这个没啥意义~
我懂你的意思了，我现在不想破坏兼容性。又要完美支持你的需求，这块天然是矛盾的。
这块要找个完善的解。我现在有点粗浅的想法，我再设计设计。明天回复你。
权衡之下，有个方法。加个全局配置。
比如
gout.NotIgnoreEmpty()//在进程启动时，只要设置一次
//任意多的gout函数都不用配置的
gout.GET(url).Debug(true).SetQuery(query).SetHeader(header).BindBody(&body).Do()这个可以，全局配置，默认调用都可以，看你怎么去设计比较好
ok，功能完成，你可以玩下。
issue先关闭，有问题你可以重新打开。