一，同步请求的最佳实践。
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的企业应用开发》
