一，同步請求的最佳實踐。

1，只在后臺過程中使用同步請求，除非確定訪問的是本地文件資源，否則請不要在主線程上使用。

2，只有在知道返回的數據不會超出應用的內存時才使用同步請求。記住，整個響應體都會位于代碼的內存中。如果響應很大，那么可能導致應用出現內存溢出問題。此外，當代碼將響應解析為所需的格式時可能需要復制返回的數據，這會導致內存增加一倍。

3，在處理返回的數據前，驗證錯誤與調用返回的HTTP響應狀態碼。

4，如果源URL需要驗證，那么不使用同步請求，因為同步框架并不支持對認證請求做出響應。唯一的例外是BASIC認證，因為這時認證信息可以通過URL或請求頭進行傳遞。以這種方式執行認證會增加應用與服務器之間的耦合度，從而導致整個應用變得更加脆弱。如果請求不使用HTTPS協議，那么還會在明文中傳遞認證信息。

5，如果需要向用戶提供進度條，那不要使用同步請求，因為請求是原子的，無法提供中間的進行指示信息。

6，如果需要通過流解析器來漸進響應數據，那么不要使用同步請求。

7，如果在請求完成前需要取消，那么不要使用同步請求。

二，隊列式異步請求的最佳實踐。

1，只有知道返回的數據不會超出應用的內存的時候才使用隊列式異步請求。記住，整個響應體都會位于代碼的內存中。如果響應很大，那么可能導致應用出現內存溢出問題，此外，當代碼將響應解析為所需的格式時可能需要復制返回的數據，這個導致內存增加一倍。

2，為所有操作使用單一的NSOperationQueue,根據服務器的能力以及預期的肉絡狀況控制當前操作的最大數量。

3，在處理返回的數據前驗證錯誤與調用返回的HTTP信啊感應狀態碼。

4，如果源URL需要驗證，那么不要使用隊列式異步請求，因為該功能不支持對認證請求做出響應。如果服務需要這種認證，那么可以將BASIC認證信息放在提供給請求的URL中。

5如果需要向用戶提供進度條，那么不要使用隊列式異步請求，因為請求是原子的，無法提供中間的進度指示信息。

6，如果需要通過流解析器來漸進解析響應數據，那么不要使用隊列式異步請求。

7，如果請求在完成前需要取消，那么不要使用隊列式異步請求。

三，異步請求的最佳實踐。

1，對于大的上傳或下載來說，請使用異步請求以減少應用的內存占用量。

2，在需要認證的情況下請使用異步請求。

3，如果需要向用戶提供進度反饋，那么請使用異步請求。

4，在后臺線程上使用異步請求要小心，請提供一個運行循環。

5，對于可以在后臺線程的請求隊列中輕松調度和完成的簡單的請求來說，這時使用異步請求有些過猶不及。

6，如果使用輸入流來上傳數據，請實現connecton:newBodyStream:方法以避免對輸入流的復制。

參考資料：《iOS網絡高級編程-iphone和iPad的企業應用開發》