自己能调通接口，别人调不通？

　　原创：打码日记（微信公众号ID：codelogs），欢迎分享，转载请保留出处。场景
　　有时我们开发了一个api接口，自己调得好好的，接口文档也写好了，但别人调用时就是有问题，而当我们调试时，发现请求根本没进来或进来了却取不到调用参数，该怎么告知对方调用姿势哪不对呢？解决方法
　　对于编码新手，一般会和对方撕扯一会，然后甚至去review对方的代码，这样也许能解决问题，但自己毕竟不熟悉别人系统的实现，耗费时间较长。
　　另外api调用端可能因为封装方式不同或者加过一些拦截器，导致你看调用端的代码根本看不到什么问题，或者因为调用参数有一些不易分辨或不可见的特殊字符，让你无法察觉到这里有问题。
　　其实这种问题，我们从网络层出发，对比自己正确调用时的数据包与对方错误调用时的数据包内容，以此来诊断问题所在更加高效，毕竟任何封装或拦截器的处理，最终都会反馈在底层的交互数据上。
　　这里，我使用springmvc开发一个简单的接口，如下：RestControllerpublicclassTestController｛RequestMapping（valuetest，producesMimeTypeUtils。TEXTPLAINVALUE）ResponseBodypublicStringtest（RequestParam（namename）Stringname）｛｝｝
　　这个接口就是直接将name参数的值返回了，然后我使用curl模拟正确与错误的调用方式，如下：正确调用方式curlhttp：localhost：8081testdataurlencodenameabab错误调用方式curlhttp：localhost：8081testdatanameabab
　　假设调用方的代码实现的逻辑类似上面错误的调用方式，传递name参数为ab，得到的却是ab，接下来我们来定位看看，错误的调用方法问题在哪？
　　方法1：使用wireshark抓包软件
　　打开wireshark，先后抓包两次正常的以及不正常的请求数据，拿到请求数据后通过文本差异对比工具来对比。如下为wireshark两次抓包结果，使用追踪流TCP，查看HTTP请求数据
　　如下为正确的HTTP请求数据，其中红色为请求数据，蓝色为响应数据
　　如下为错误的HTTP请求数据
　　对比请求数据差异
　　可以看出，一个请求name参数为a2Bb，一个请求name参数为ab，显然这是由于name参数值没有urlencode导致的。
　　另外或许你会奇怪，为啥错误请求值为ab，为啥代码里面获取到的却是ab？原因是tomcat接收到请求参数后，会做一次urldecode，而号会被decode为空格，java的URLDecoder。decode（ab，UTF8）也是如此。
　　方法2：使用socat命令
　　在抓包工具无法使用的情况下，可以尝试socat命令，使用socat命令来中转请求，调用端将请求先发给socat，socat再把请求转给服务端，如下：使用socat中转请求socatvTCP4LISTEN：8080，bind0。0。0。0，reuseaddr，forkTCP4：localhost：8081调用端访问socat监听的8080端口正确调用方式curlhttp：localhost：8080testdataurlencodenameabab错误调用方式curlhttp：localhost：8080testdatanameabab
　　再去看socat，会发现如下结果：
　　其中socat添加v参数后，会自动将中转的数据流以明文显示出来，其中类似2020101113：05：03。536294length162from0to161之后的部分，就是请求数据，而类似2020101113：05：03。740585length116from0to115之后的部分，就是响应数据，同样的，你可以将两次请求数据复制到文本对比工具中去发现差异。
　　有时这种调用差异是特殊字符导致的，比如空白字符、零宽字符，上面的方式可能看不出差异，这时你可以将v参数替换为x参数，来对比数据的十六进制，同样的wireshark也可以查看数据包的十六进制，相信你摸索一下也可以找到。举一反三
　　此外，有些时候，我们写的代码去查询数据库时，查不到数据，但我们把SQL拿到数据库客户端工具中，却可以查到数据，这种问题极有可能是SQL被底层一些拦截器改写了，这时，我们也可以使用上面的方法来确认，这里仅仅介绍使用socat的方式，如下，使用socat中转数据库连接：1。中转数据库连接socatvTCP4LISTEN：3307，bind0。0。0。0，reuseaddr，forkTCP4：localhost：330621teedata。log2。然后我们代码中连接数据库的地方，将端口改成3307，然后执行我们的SQL查询3。查看真实发送给数据库的SQLcatdata。loggrepiselect
　　结果如下：
　　我相信到这一步，大概能发现SQL差异了，接下来就是找到底层修改SQL的代码在哪，以及如何处置了。总结
　　遇到这种网络调用上的差异问题，多多考虑使用wireshark、socat、ncat之类的网络工具来处理，相信问题处理效率会大大增加。