本文主要總結iOS網絡層搭建中需要考慮的一些問題，注意這裡真的只是列出了要解決哪些問題，並沒有提出解決方案。如果有好的解決方法可以分享一下。那麼問題來了！

調用方式

• 是使用集約型調用如下:

[ObjectClass postDataWithURL:url params:params  class:class success:success failure:failure];

• 所有的請求都集中在一個類中，每個請求都是一個類方法，一般回調采用Block；

• 還是使用離散型調用：

[instance loadDataWithParams:params success:success failure:failure];

• 每個請求都建立一個對象，使用時實例化對象並調用實例方法，可能對象會比較多，但是對象多不好嗎洗衣服的一個，暖床的一個。。。yy了回調的話使用delegate和block，通知什麼的也有。
  那你會選擇使用誰呢？優缺點各是什麼呢？

發起請求

• 請求發起的條件
  當用戶不停的下拉刷新的時候，怎樣避免每次下拉去發起一個請求呢？判斷當前沒有請求的時候再發起請求？還是取消前一次發起的請求呢？用戶在買商品的時候不停的再篩選，這個時候又怎麼發起請求呢？

• 一個頁面多個請求
  一個頁面的數據由多個API返回的數據組成，APIs全部請求完成再開始刷新界面，這又如何處理呢？例如sectionHeader是一個API返回數據，tableView是另一個API返回的數據。

• 請求嵌套
  一個API返回的數據是另一個API的參數，例如先獲取用戶的ID，再用這個ID作為參數去請求用戶收藏的文章。

• 分頁請求
  tableView分頁請求，怎樣封裝才能讓我們只需要調用接口，而不需要每次都關心++pageNumber呢?
  我們怎麼才能處理好上述的情況呢？一個對象還是什麼？

回調方式

回調方式一般有Block，通知，KVO，delegate。這幾種方式本身並無好壞，不同場景都有自己的優勢。
成功和失敗的回調是處理之後再返回呢？還是直接返回？怎麼和業務層對接？

說個故事：有次需要修改某次請求成功後的邏輯，項目回調采用的是Block，請求是在Controller發起的，但是成功時回調的Block的實現並不在Controller中，將Block傳給了一個View，view中繼續傳給了一個View。我不知道這樣的缺點，但是我找起來真的好麻煩好嗎？block可能還會延遲Controller的釋放，請求發起之後，立馬返回。Controller是不會立馬釋放的。當然weak可以解決

那麼這幾種回調你采用的是哪一種呢？或者更傾向於哪一種呢？

緩存

• 讀取本地緩存的同時去請求數據
  例如微博，先展示上次請求的數據，當請求成功時候在替換調舊的數據刷新界面並保存在本地供下次使用。這樣用戶就不會傻傻的對著一個空白界面盯著菊花了。

• 只讀取本地緩存
  對於一些幾乎不會變化的數據，請求一次就保存，以後只讀取本地數據。比如k12教育類app的年級，幾乎是不會變的。

• 短時間內的緩存
  用戶的信息不會不停的被修改的，用戶不會那麼無聊。那麼獲取用戶信息的接口我們就可以設置一個59分鐘的緩存。緩存時間內請求只讀取本地數據，過期之後才會重新請求。

安全

某次比較閒，試試能不能抓包修改公司一個購買課程的app的課程價格，然而就這樣成功了！兩千被改成一毛。後來後台加了一個驗證。就是將返回的數據，加密加密在加密，然後移動端作比對。如果比對不成功，那麼就是數據在傳輸過程中被修改了。

那麼采用什麼樣的安全機制呢？https？各種加密？

網上有很多例子，基本都解決上述的問題。畢竟帶著問題再看如何解決問題，更有效果。