轉(zhuǎn)載請注明出處 http://m.itdecent.cn/p/cccdf48ea8d4 (作者：韓棟)
本文為譯文，由于譯者水平有限，歡迎拍磚，讀者也可以閱讀原文
【OkHttp3-基本用法，OkHttp3-使用進階（Recipes），OkHttp3-請求器（Calls），OkHttp3-連接（Connections），OkHttp3-攔截器（Interceptor）】

OkHttp客戶端負責(zé)接收應(yīng)用程序發(fā)出的請求，并且從服務(wù)器獲取響應(yīng)返回給應(yīng)用程序。理論聽起來十分簡單，但是在實踐中往往會出現(xiàn)很多意想不到的因素。

請求 (Request)

每一個Http請求都包含一個URL和一個請求方式（比如Get或者Post），以及一些請求頭信息。請求也有可能包含一個請求主體：當(dāng)一個數(shù)據(jù)流存在指定的content type類型的請求頭時。

響應(yīng) (Responses)

服務(wù)器根據(jù)請求向你的應(yīng)用程序返回響應(yīng)，此響應(yīng)包含了一個狀態(tài)碼（比如200表示請求成功，404表示請求失?。?、響應(yīng)頭、以及可能包含的響應(yīng)主體。

重寫請求 (Rewriting Requests)

OkHttp所發(fā)出去的每個Http請求都是高等級的：`“fetch me this URL with these headers.”。為了請求的正確性和高效性，OkHttp在數(shù)據(jù)傳輸之前會自動重寫你的請求。

OkHttp可以自動為你的請求添加一些請求所沒有的請求頭，包括Content-Length、Transfer-Encoding、User-Agent、Host、Connection，以及Content-Type。 如果你的原生請求中沒有定義Accept-Encoding類型，那么OkHtpp會自動為請求添加Accept-Encoding類型為Gzip，以此希望服務(wù)端能返回壓縮過的數(shù)據(jù)。如果應(yīng)用程序中存在Cookies，那么OkHttp將會自動將它們添加到你的請求的Cookie頭部信息中。

OkHttp會將一些請求的響應(yīng)緩存起來。當(dāng)其中的一個緩存過期時，OkHttp將會發(fā)送一個帶有特定的請求頭信息（比如If-Modified-Since或者If-None-Match），并且以Get方式請求去重新從服務(wù)器上獲取數(shù)據(jù)，并且如果所獲取的新數(shù)據(jù)與舊的緩存數(shù)據(jù)不一致，OkHttp將新的數(shù)據(jù)保存覆蓋掉舊的緩存。

重寫響應(yīng) (Rewriting Responses)

如果響應(yīng)主體是經(jīng)過壓縮處理，那么OkHttp會自動將響應(yīng)頭部中的Content-Encoding和Content-Length去掉，因為它們并不適用于解壓縮響應(yīng)主體的操作。

如果一個請求方法為Get的網(wǎng)絡(luò)請求執(zhí)行成功，那么正常情況下從服務(wù)器返回的響應(yīng)將會和緩存進行合并。

跟蹤請求 (Follow-up Requests)

當(dāng)你所請求的主機的URL發(fā)生改變時，服務(wù)器將會返回一個為302的響應(yīng)狀態(tài)碼以及新的URL信息。OkHttp將會根據(jù)這個URL進行重定向操作，并且再次向新的URL發(fā)送請求獲取數(shù)據(jù)。

當(dāng)你發(fā)送請求時，服務(wù)器可能會返回一個響應(yīng)告訴你需要進行身份基本認證，那么OkHttp此時會自動告訴Authenticator去解決這個認證問題，當(dāng)然，Authenticator需要你自己進行配置。Authenticator處理身份認證通過時會獲取到認證成功憑證，OkHttp會攜帶著它再次向服務(wù)器發(fā)送原來的請求。

重試請求 (Retrying Requests)

有的時候會發(fā)生連接失敗：可能連接池過期而導(dǎo)致連接斷開，或者請求的服務(wù)器無法找到。OkHttp將會不斷嘗試不同的可用線路去發(fā)送請求。

請求器 (Calls)

通過重寫、重定向、跟蹤以及重試，你發(fā)送的一個簡單的請求可能會變成需要發(fā)送多個請求以及接收多次響應(yīng)之后才能獲得最后的想要的響應(yīng)。OkHttp會將這些全部請求以及響應(yīng)（你的一個請求任務(wù)）塑造成一個Call對象，然而請求過程中所發(fā)生的多次請求以及響應(yīng)是必須的。但是通常情況下中間請求及響應(yīng)工作不會很多！令人欣慰的是，無論發(fā)生URL重定向還是因為服務(wù)器出現(xiàn)問題而向一個備用IP地址再次發(fā)送請求的情況，你的代碼都會一直正常運行。

執(zhí)行Call有兩種方式：

• 同步：請求和處理響應(yīng)發(fā)生在同一線程。并且此線程會在響應(yīng)返回之前會一直被堵塞。
• 異步：請求和處理響應(yīng)發(fā)生在不同線程。將發(fā)送請求操作發(fā)生在一個線程，并且通過回調(diào)的方式在其他線程進行處理響應(yīng)。（一般在子線程發(fā)送請求，主線程處理響應(yīng)）

Calls可以在任何線程被取消。當(dāng)這個Call尚未執(zhí)行結(jié)束時，執(zhí)行取消操作將會直接導(dǎo)致此Call失?。‘?dāng)一個Call被取消時，無論是寫入請求主體或者讀取響應(yīng)主體的代碼操作，都會拋出一個IOException異常。

調(diào)度者 (Dispatch)

對于在同步線程中執(zhí)行Call而言，你最好創(chuàng)建子線程并且手動管理你所發(fā)出的并發(fā)請求。因為太多并發(fā)連接浪費資源，以及可能會導(dǎo)致發(fā)生一些不好的小問題。

對于異步線程執(zhí)行Call而言，Dispactcher實現(xiàn)了一個限制最大并發(fā)的接口。你也可以自定義設(shè)置對于每臺主機的最大并發(fā)數(shù)（默認為5），以及總的并發(fā)數(shù)（默認為64）。