Python Requests.post()請(qǐng)求失敗retry設(shè)置

1. 問題描述

通常，我們?cè)谧雠老x工作或遠(yuǎn)程接口調(diào)用的過(guò)程中，往往由于訪問頻率過(guò)快等原因遇到連接超時(shí)的報(bào)錯(cuò)問題，利用最近調(diào)用api.ai.qq.com某個(gè)接口舉例如下：

Traceback (most recent call last):
<class 'Exception'> : HTTPSConnectionPool(host='api.ai.qq.com', port=443):
Max retries exceeded with url: /fcgi-bin/nlp/nlp_textpolar (Caused by ProxyError('Cannot connect to proxy.', OSError('Tunnel connection failed: 504 Gateway Time-out',)))

用代碼格式顯示更為清晰：

Traceback (most recent call last):
<class 'Exception'>  :  HTTPSConnectionPool(host='api.ai.qq.com', port=443):
 Max retries exceeded with url: /fcgi-bin/nlp/nlp_textpolar (Caused by ProxyError('Cannot connect to proxy.', 
OSError('Tunnel connection failed: 504 Gateway Time-out',)))

之前寫爬蟲時(shí)候?yàn)榱丝焖俳鉀Q問題就寫了一堆的while與try來(lái)實(shí)現(xiàn)鏈接的重新訪問，這種方式可以在一定程度上解決問題，但回看自己的代碼時(shí)候總覺得奇丑無(wú)比，今天在做一個(gè)遠(yuǎn)程接口調(diào)用時(shí)候又遇到這個(gè)報(bào)錯(cuò)，想著python的requests模塊中一定有內(nèi)置方法來(lái)解決這個(gè)問題，于是便嘗試了一下，但同時(shí)又引發(fā)了另一個(gè)小問題，遂決定記錄一下。

2. 解決方案

其實(shí)，我們?cè)趆ttp請(qǐng)求中遇到連接超時(shí)導(dǎo)致訪問中斷的情況時(shí)，往往不需要自己來(lái)寫重訪問策略，requests模塊中有對(duì)應(yīng)的重訪問設(shè)置，可以通過(guò)設(shè)置最大重訪問次數(shù)，當(dāng)一次訪問失敗時(shí)，會(huì)自動(dòng)進(jìn)行重新訪問，實(shí)現(xiàn)方式（簡(jiǎn)化）如下：

import requests
from requests.adapters import HTTPAdapter
from requests.packages.urllib3.util import Retry
s = requests.Session()
s.mount('https://', HTTPAdapter(max_retries=Retry(total=5)))
resp_get = s.get(url=http_url, data={'key':'value'})
resp_post = s.post(url=http_url, data={'key':'value'})

可以看到，我們?cè)O(shè)置最大重訪問次數(shù)為5。但此時(shí)會(huì)發(fā)現(xiàn)，如果我們使用的是 get() 方法的話則沒有問題，但如果使用 post() 方法的話仍然會(huì)報(bào)錯(cuò)。

通過(guò)查資料發(fā)現(xiàn)，python的requests模塊使用的urllib3，而urllib3默認(rèn)對(duì) post() 方法不設(shè)置重訪問，因此需要我們手動(dòng)指定才可以，修改如下：

import requests
from requests.adapters import HTTPAdapter
from requests.packages.urllib3.util import Retry
s = requests.Session()
s.mount('https://', HTTPAdapter(max_retries=Retry(total=5, method_whitelist=frozenset(['GET', 'POST'])))) # 設(shè)置 post()方法進(jìn)行重訪問
resp_get = s.get(url=http_url, data={'key':'value'})
resp_post = s.post(url=http_url, data={'key':'value'})

這樣再使用requests.post()時(shí)幾乎不會(huì)出現(xiàn)超時(shí)中斷的情況了！

python requests.post請(qǐng)求404

問題場(chǎng)景

有時(shí)候，在編寫一段http接口請(qǐng)求程序時(shí)，發(fā)現(xiàn)代碼中的header頭和請(qǐng)求體中都是原網(wǎng)頁(yè)中一樣，但是，在實(shí)際請(qǐng)求時(shí)，接口卻返回404，代碼如下

header = {
    # ':authority': 'm.ctrip.com',
    # ':method': 'POST',
    # ':path': '/restapi/soa2/20405/getPCSightList',
    # ':scheme': 'https',
    'accept': '*/*',
    'accept-encoding': 'gzip, deflate, br',
    'accept-language': 'zh-CN,zh;q=0.9',
    'authorization': 'xx',
    'cache-control': "no-cache",
    'content-length': '373',
    'content-type': 'application/json;charset:utf-8;',
    'cookies': 'xx',
    'origin': 'https://www.tripadvisor.cn',
    'pragma': 'no-cache',
    'referer': 'https://www.tripadvisor.cn/Attractions-g60763-New_York_City_New_York-Vacations.html',
    'sec-ch-ua': "'.Not/A)Brand';v='99', 'Google Chrome';v='103', 'Chromium';v='103'",
    'sec-ch-ua-mobile': '?0',
    'sec-ch-ua-platform': 'macOS',
    'sec-fetch-dest': 'empty',
    'sec-fetch-mode': 'cors',
    'sec-fetch-site': 'cross-site',
    'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36',
    'x-ta-uid': 'cd58b674-7dba-484a-a908-3239120cd728'
}
url = 'https://m.ctrip.com/restapi/soa2/20405/getPCSightList'
data = {"geoId":60763,"pageIndex":1,"pageSize":30,"travelRanking":"false","needSelectedFilters":"true","filters":[{"type":"subcategory","param":""},{"type":"subtype","param":""},{"type":"neighborhood","param":""},{"type":"travelerRating","param":""},{"type":"awards","param":""},{"type":"waypointairport","param":""},{"type":"waypointstation","param":""},{"type":"other","param":""}]}
response = requests.post(url=url, data=data, headers=header)
print(response.status_code)

運(yùn)行結(jié)果為

問題分析

既然404，那就排查問題，data和header都是直接從復(fù)制瀏覽器中復(fù)制過(guò)來(lái)的，不會(huì)有問題，那有問題的必然是request.post中的方法問題

• 查看request.post源碼

從源碼中可以看到，request.post可以接受兩個(gè)參數(shù)，一個(gè)是data，還有一個(gè)是json，

data是以字典的形式發(fā)送body，json則是以json數(shù)據(jù)格式發(fā)送body

通過(guò)這兩個(gè)注釋可以很明顯的發(fā)現(xiàn)，requests.post在發(fā)送請(qǐng)求時(shí)，會(huì)根據(jù)當(dāng)前傳遞的參數(shù)來(lái)選擇不同的方式，可以理解為一種是表單形式，還有一種是json格式

• postman測(cè)試

通過(guò)postman來(lái)測(cè)試兩種不同請(qǐng)求下的情況

form表單

Json數(shù)據(jù)

通過(guò)postman測(cè)試可以發(fā)現(xiàn)，當(dāng)前服務(wù)后端接口僅接受json格式的數(shù)據(jù)，即content-type為application.json

問題解決

將原先代碼中data替換成json

response = requests.post(url=url, json=data, headers=JsonHeader)

這個(gè)時(shí)候肯定有人會(huì)問，那我使用data傳遞數(shù)據(jù)時(shí)，將header頭中的content-type指定為application/json不就行了，但其實(shí)是不行的，就算自己指定了，最后request.body的值也是類似于key1=value1&key2=value2這種形式

心得

1.當(dāng)request.post使用json來(lái)傳遞參數(shù)時(shí)，即使不指定content-type類型，也會(huì)默認(rèn)指定application/json

2.使用data傳遞參數(shù)時(shí)，將會(huì)以表單的形式進(jìn)行提交，并且后續(xù)將通過(guò)urlencode轉(zhuǎn)換成字符串，及key1=value1&key2=value2的形式

3.使用data時(shí)，即使指定了content-type也不會(huì)生效，后續(xù)將會(huì)被默認(rèn)替換掉

因此，需要根據(jù)自己實(shí)際情況來(lái)分析當(dāng)前接口接收數(shù)據(jù)時(shí)使用的是什么格式，但目前一般的網(wǎng)站都開始采用application/jsond的數(shù)據(jù)格式

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論