發送請求
使用requests發送網絡請求非常簡單，一開始需要導入requests模塊：
import requests
然後，嘗試獲取某個網頁。舉個例子，我們來獲取Github的公共時間線：
r = requests.get('https://api.github.com/events')
現在，我們有了一個命名爲r的Response對象，我們可以從這個對象中獲取所有我們想要的信息。
requests簡便的API意味着所有HTTP請求類型都是顯而易見的，例如，我們可以這樣發送一個HTTP post請求：
r = requests.post('http://httpbin.org/post', data = {'key':'value'})
同樣也可以發送其他http請求類型：put,delete,head以及options
r = requests.put('http://httpbin.org/put', data = {'key':'value'})
r = requests.delete('http://httpbin.org/delete')
r = requests.head('http://httpbin.org/get')
r = requests.options('http://httpbin.org/get')
傳遞URL參數
也許你想爲URL的查詢字符串傳遞某種數據，如果你是手工構建URL，那麼數據會以鍵/值對的形式置於URL中，跟在一個問號的後面。例如， httpbin.org/get?key=val。
requests允許使用params關鍵字參數，以一個字符串字典來提供這些參數。舉例如下，如果你想傳遞key1=value2和key2=value2到httpbin.org/get，那麼你可以使用如下代碼：
payload = {'key1':'value1', 'key2':'value2'}
r = requests.get('http://httpbin.org/get', params = payload)
print(r.url)
通過打印輸出該URL，你可以看到URL已經被正確編碼：
注意字典裏值爲 None 的鍵都不會被添加到 URL 的查詢字符串裏。
你還可以將一個列表作爲值傳入：
響應內容
我們能讀取服務器響應的內容。再次以Github時間線爲例：
import requests
r = requests.get('https://api.github.com/events')
print(r.text)
結果如下：
Requests 會自動解碼來自服務器的內容。大多數 unicode 字符集都能被無縫地解碼。
請求發出後，Requests 會基於 HTTP 頭部對響應的編碼作出有根據的推測。當你訪問 r.text 之時，Requests 會使用其推測的文本編碼。你可以找出 Requests 使用了什麼編碼，並且能夠使用r.encoding 屬性來改變它：
如果你改變了編碼，每當你訪問 r.text ，Request 都將會使用 r.encoding 的新值。你可能希望在使用特殊邏輯計算出文本的編碼的情況下來修改編碼。比如 HTTP 和 XML 自身可以指定編碼。這樣的話，你應該使用 r.content 來找到編碼，然後設置 r.encoding 爲相應的編碼。這樣就能使用正確的編碼解析 r.text 了。
在你需要的情況下，Requests 也可以使用定製的編碼。如果你創建了自己的編碼，並使用 codecs模塊進行註冊，你就可以輕鬆地使用這個解碼器名稱作爲 r.encoding 的值， 然後由 Requests 來爲你處理編碼。
二進制響應內容
你也能以字節的方式訪問請求響應體，對於非文本請求：
Requests 會自動爲你解碼 gzip 和 deflate 傳輸編碼的響應數據。
例如，以請求返回的二進制數據創建一張圖片，你可以使用如下代碼：
JSON 響應內容
Requests 中也有一個內置的 JSON 解碼器，助你處理 JSON 數據：
如果 JSON 解碼失敗， r.json() 就會拋出一個異常。例如，響應內容是 401 (Unauthorized)，嘗試訪問 r.json() 將會拋出 ValueError: No JSON object could be decoded 異常。
需要注意的是，成功調用 r.json() 並**不**意味着響應的成功。有的服務器會在失敗的響應中包含一個 JSON 對象（比如 HTTP 500 的錯誤細節）。這種 JSON 會被解碼返回。要檢查請求是否成功，請使用 r.raise_for_status() 或者檢查 r.status_code 是否和你的期望相同。
原始響應內容
在罕見的情況下，你可能想獲取來自服務器的原始套接字響應，那麼你可以訪問 r.raw。 如果你確實想這麼幹，那請你確保在初始請求中設置了 stream=True。具體你可以這麼做：
但一般情況下，你應該以下面的模式將文本流保存到文件：
使用 Response.iter_content 將會處理大量你直接使用 Response.raw 不得不處理的。 當流下載時，上面是優先推薦的獲取內容方式。 Note that chunk_size can be freely adjusted to a number that may better fit your use cases.
定製請求頭
如果你想爲請求添加 HTTP 頭部，只要簡單地傳遞一個 dict 給 headers 參數就可以了。
例如，在前一個示例中我們沒有指定 content-type:
注意: 定製 header 的優先級低於某些特定的信息源，例如：
- 如果在
.netrc中設置了用戶認證信息，使用 headers= 設置的授權就不會生效。而如果設置了auth=參數，``.netrc`` 的設置就無效了。 - 如果被重定向到別的主機，授權 header 就會被刪除。
- 代理授權 header 會被 URL 中提供的代理身份覆蓋掉。
- 在我們能判斷內容長度的情況下，header 的 Content-Length 會被改寫。
更進一步講，Requests 不會基於定製 header 的具體情況改變自己的行爲。只不過在最後的請求中，所有的 header 信息都會被傳遞進去。
注意: 所有的 header 值必須是 string、bytestring 或者 unicode。儘管傳遞 unicode header 也是允許的，但不建議這樣做。
更加複雜的 POST 請求
通常，你想要發送一些編碼爲表單形式的數據——非常像一個 HTML 表單。要實現這個，只需簡單地傳遞一個字典給 data 參數。你的數據字典在發出請求時會自動編碼爲表單形式：
你還可以爲 data 參數傳入一個元組列表。在表單中多個元素使用同一 key 的時候，這種方式尤其有效：
很多時候你想要發送的數據並非編碼爲表單形式的。如果你傳遞一個 string 而不是一個 dict，那麼數據會被直接發佈出去。
例如，Github API v3 接受編碼爲 JSON 的 POST/PATCH 數據：
此處除了可以自行對 dict 進行編碼，你還可以使用 json 參數直接傳遞，然後它就會被自動編碼。這是 2.4.2 版的新加功能：
POST一個多部分編碼(Multipart-Encoded)的文件
Requests 使得上傳多部分編碼文件變得很簡單：
你可以顯式地設置文件名，文件類型和請求頭：
url = 'http://httpbin.org/post'
files = {'file': ('report.xls', open('report.xls', 'rb'), 'application/vnd.ms-excel', {'Expires': '0'})}
r = requests.post(url, files=files)
r.text
輸出如下：
如果你想，你也可以發送作爲文件來接收的字符串：
如果你發送一個非常大的文件作爲 multipart/form-data 請求，你可能希望將請求做成數據流。默認下 requests 不支持, 但有個第三方包 requests-toolbelt 是支持的。你可以閱讀 toolbelt 文檔來了解使用方法。
在一個請求中發送多文件參考 高級用法 一節。
響應狀態碼
我們可以檢測響應狀態碼：
爲方便引用，Requests還附帶了一個內置的狀態碼查詢對象：
如果發送了一個錯誤請求(一個 4XX 客戶端錯誤，或者 5XX 服務器錯誤響應)，我們可以通過Response.raise_for_status() 來拋出異常：
但是，由於我們的例子中 r 的 status_code 是 200 ，當我們調用 raise_for_status() 時，得到的是：
一切都挺和諧哈。
響應頭
我們可以查看以一個 Python 字典形式展示的服務器響應頭：
但是這個字典比較特殊：它是僅爲 HTTP 頭部而生的。根據 RFC 2616， HTTP 頭部是大小寫不敏感的。
因此，我們可以使用任意大寫形式來訪問這些響應頭字段：
它還有一個特殊點，那就是服務器可以多次接受同一 header，每次都使用不同的值。但 Requests 會將它們合併，這樣它們就可以用一個映射來表示出來，參見 RFC 7230:
A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma.
接收者可以合併多個相同名稱的 header 欄位，把它們合爲一個 "field-name: field-value" 配對，將每個後續的欄位值依次追加到合併的欄位值中，用逗號隔開即可，這樣做不會改變信息的語義。
Cookie
如果某個響應中包含一些 cookie，你可以快速訪問它們：
要想發送你的cookies到服務器，可以使用 cookies 參數：
Cookie 的返回對象爲 RequestsCookieJar，它的行爲和字典類似，但接口更爲完整，適合跨域名跨路徑使用。你還可以把 Cookie Jar 傳到 Requests 中：
重定向與請求歷史
默認情況下，除了 HEAD, Requests 會自動處理所有重定向。
可以使用響應對象的 history 方法來追蹤重定向。
Response.history 是一個 Response 對象的列表，爲了完成請求而創建了這些對象。這個對象列表按照從最老到最近的請求進行排序。
例如，Github 將所有的 HTTP 請求重定向到 HTTPS：
如果你使用的是GET、OPTIONS、POST、PUT、PATCH 或者 DELETE，那麼你可以通過 allow_redirects 參數禁用重定向處理：
如果你使用了 HEAD，你也可以啓用重定向：
超時
你可以告訴 requests 在經過以 timeout 參數設定的秒數時間之後停止等待響應。基本上所有的生產代碼都應該使用這一參數。如果不使用，你的程序可能會永遠失去響應：
>>> requests.get('http://github.com', timeout=0.001)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
requests.exceptions.Timeout: HTTPConnectionPool(host='github.com', port=80): Request timed out. (timeout=0.001)
注意
timeout 僅對連接過程有效，與響應體的下載無關。 timeout 並不是整個下載響應的時間限制，而是如果服務器在 timeout 秒內沒有應答，將會引發一個異常（更精確地說，是在timeout 秒內沒有從基礎套接字上接收到任何字節的數據時）If no timeout is specified explicitly, requests do not time out.
錯誤與異常
遇到網絡問題（如：DNS 查詢失敗、拒絕連接等）時，Requests 會拋出一個 ConnectionError 異常。
如果 HTTP 請求返回了不成功的狀態碼， Response.raise_for_status() 會拋出一個 HTTPError異常。
若請求超時，則拋出一個 Timeout 異常。
若請求超過了設定的最大重定向次數，則會拋出一個 TooManyRedirects 異常。
所有Requests顯式拋出的異常都繼承自 requests.exceptions.RequestException 。