一个值得深思的小问题 - 请求中的参数值为空要不要携带该参数？

最近一个朋友疯狂的和我吐槽公司的后端，说很常规、很普通的一个事儿，也就是验证一下子的事儿，非要搞的那么复杂，治标不治本，技术玩来玩去不但没进步还倒退了。

这是怎么回事呢？咱们就来聊聊这件"小事儿"，大家可以看看自己内部是怎么做的。

咱们都是搞前端的，所以和后端打交道最多的就是调用后端接口获取数据,每个公司应该也都有自己的接口规范，传参规范等。

我这朋友的问题是这样的，前端请求接口，带过去了一些参数，但是其中有个参数没值，也就是空，但是呢后端在接收该值的时候没有类型判断（该字段是int类型），相当于直接把一个空字符串直接转为int类型。结果可想而知了，肯定是出异常了。导致业务上受到了影响。

比如,请求参数如下

name=bigerfe&age=&a=1

其中参数age是int类型，但是前端传了空，后端取参数的时候报错了。

此时，前端理解的是后端只需要后端做个容错处理就可以了，转化失败就给个默认值呗。但是后端理解的不太一样了，希望前端如果是没值的这种字段，就直接不要拼接到参数里，这种空串对于我们来说是没意义的，没意义的就不需要拼接了。然后要出一个传参规范，声明string类型的字段如果值为空串的，请求的时候就不要携带该参数。其他类型的会给一个默认值。

比如这样,age字段干掉了

name=bigerfe&a=1

我这朋友不乐意了，觉得这不合理，认为本质问题就是兜底处理没做好，怎么扯到规范上来了，觉得这个规范对他们的影响挺大，需要改代码，不能接收这个提议，但当时也不能说出一个更合理的理由，只能忍着。

其实我们客观来分析下，解决这个问题的最简单的方法就是后端做好容错处理，转换失败给个默认值，提到规范层面也不是不可以，但是要先明确问题产生的原因。

既然要做规范，这也是好事，这样各端就都统一了，也能让其他端避免再出现该问题，若遇到什么问题，不清楚的直接去查规范就好了。

如果后端初定了上面这样的规范，然后和大家一起讨论，看是否可行，如果你觉得不合理，你该如何反驳呢？

既然你觉得不合理，你觉得怎样合理？

有时候你觉得不合理，可能是你不想做，你没有这样的习惯而已。

你可能会说，不携带这个参数和传空串完全是两个意义。

如果是你遇到了这个问题，你该怎样处理？接受还是反驳？能不能找到一个走不通的场景？

。。。。。。。

毕竟该规范是不合理的，人多了总有人能想到不同的场景，在团队的讨论下，结果该方案没有通过，还是保持原来的方式，不会干掉这个字段。

1. 接口规范中为每个字段说明其类型，并且给出默认值

2. 服务端做统一的类型验证，不符合的直接给出错误码

那是被什么样的问题给拍回去了呢？

1. 如果这个字段是必填的，而且是空串，那这个字段可以带吗？你给什么默认值？

2. 比如我在后台要修改某个人的信息，改为空，怎么办？走不通了吧！

好了，别的不多说了，可能还有其他的场景，大家可以留言来讨论。

最后，有时候我们可能觉得某些方案不合理，但是一时也想不出去为什么不合理？其实也能做，但就是不想做，可能成本高，影响范围大。但如果真的不合理，那一定要拿出不合理的理由，或者在某些场景下走不通，而不是通过经验来说这样不合理。另外，有时候一个人想不出理由也很正常，所以这个时候就需要团队一起来讨论，把方案拿出来，合理不合理很快就见分晓，毕竟一个人的力量是有限的，人多了想法多，思考的角度也不同。通过讨论才能有更好的结论，这可能也就是团队存在的一个重要意义吧。

另外我们自己也不能处处依赖团队，时刻应该调整自己思考问题的方向和思路，当遇到不合理的方案的时候，不要陷入代码层面去，也不要只考虑自身的工作量，更不要被以往的经验和习惯给束缚了，应该跳出代码，多考虑业务中的实际场景，看是否都能满足。

点赞是最大的支持