踩坑python之requests发送post请求
目录索引
本文阅读大约需要2分钟。
前言
噢，我亲爱的老弟，让我来看看是哪个小可爱又踩坑了。
没错，就是我。
本次踩坑实属大无语事件，世界就是一个巨大的草台班子，原来老鸟也会翻车。
今天，对着练习时长两年半的python开始唱跳，谁知道在request请求时，怎么修改操作都不对，最后卡了我两三个小时。
痛定思痛，决定把这次事件钉在耻辱柱上，方便反思。
缘起
所有的爱和恨都不会无缘无故产生，我站在回溯的立场时才明白。
临时中途插入一个朋友的python自动化办公项目，由于某些特殊原因，我只能在打包之后发送到对方机器上进行测试。这是其一。
这个自动化办公针对的对象是一个web服务，但是服务器权限是别人的，我无法在服务器进行打印。这是其二。
这个自动化项目有个需求，需要每隔10分钟左右才进行一次特殊逻辑处理，而这个逻辑恰好包含一个requests发送post请求，请求头是application/x-www-form-urlencoded。这是其三。
三个东西一叠加，直接原地爆炸。出现问题调试感觉很费时费力呀。
走错的路
为了捕捉requests的请求错误，我习惯在外面包一层try-catch。
本以为是个普通post请求，chrome下网络请求一看，我就开始着手写代码，本以为so easy，因为根据过往经验大多数网站的请求扛不住我三十分钟敲键盘的双手。
代码如下：
try:
payload = {
"a": "a",
"b": "b",
"c": [{"test": "test1"}]
}
response = requests.get(
self._api_url,
json=payload
headers=headers,
timeout=5)
if response.status_code == 200:
# 其他逻辑
return False
else:
self._logger.debug("api ：返回错误的状态码")
return False
except requests.Timeout:
self._logger.debug("api 超时")
return False
except requests.RequestException as e:
self._logger.debug("api 异常:" + str(e))
return False
except BaseException as e:
self._logger.debug("api 出现错误:" + str(e))
return False
经验主义害死人，代码自测阶段调试时发现这个请求接收到服务器的响应刚开始报错或者响应结果不符合预期。
就开始了初步排查，最后一看chrome请求头，我才注意到"Content-type: application/x-www-form-urlencoded"，然后我开始意识到第一个不对劲，说来轻巧，但是在调试问题上不好操作导致两轮打包+测试下来已经过了半小时左右。
随即我将json=payload改为了data=paylod，写到这里，我十分确信我走在正确的道路上，我已经开始幻想我摆脱苦难和折磨，灵魂一路飘到了南天门。
下一秒，跌落凡尘。
诶？什么鸟服务端？居然敢拒绝python练习时长两年半的我？
啊，大哥，你为啥不返回预期结果？
我错乱了，大爷，放我过去吧？
几轮调试加修改下来，毫无起色，又过去了一个多小时。
在此期间，我先是严格排查请求参数是否一致，又排查了headers确保和浏览器发送请求一致，并且确认上下部分逻辑是否有误。
最终，再次点开chrome查看原始参数，我开始意识到不对了。
随即使出江湖普遍流传的cv大法加搜索引擎大法，然后离奇的是，直到我看到下面类似的代码时，我还任然执迷不悟。
datas={
'conditions':'[{"test1":"demo","tt":0}]'}
}
殊不知，苦海无边，回头方是岸。
又经过几分钟的情绪波动，我耐下心来，终于发现了关键，字符串，它居然是字符串。
因为在我的代码中，上面有一堆逻辑处理，把数据处理好之后才append到list，然后再赋值list给data。
最终决定赋值时加一个json.dumps()转为字符串，然后就可以了。
总结
1、如果能够改善，或者直接在开发机进行调试和测试应该节省大量时间。
2、还是cv大法香，cv保平安，解决问题的途径有很多种，不要陷入死胡同。
3、耐心和细心虽然不一定能直接解决问题，但是一定能提高很多效率。
4、不要盲目相信过去的经验，很多时候虽然处理思路和方法总体相同，但是也容易让自己忽视自己很菜。
所属分类：
前端
文章标签：
#python
#requests