iOS 學習 RESTful 中 Http 的冪等性

一. RESTful 

  RESTful (Representational State Transfer) 是一種經常使用流行的軟件架構，設計風格或協議標準。提供了一組設計風格和約束條件。主要用於客戶端和服務端的交互。

 1. 統一資源接口

 2.使用http方法

   iOS 以AFNetworking 爲例

typedef NS_ENUM(NSUInteger, HTTPMethod) {
    GET = 10,
    HEAD,
    POST,
    PUT,
    PATCH,
    DELETE
};
 

    2.1 冪等性（idempotent、idempotence）

      Methods can also have the property of 「idempotence」 in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is

      the same as for a single    request.

   ——HTTP/1.1規範中冪等性的定義

  （1）冪等性是數學中的一個概念，表達的是N次變換與1次變換的結果相同

  （2）「發起一個指定請求 N 次，獲得的結果影響應該是一致的」

  （3）http 冪等性 針對的是請求結果 不是請求資源內容

 

        GET 冪等性：不論請求多少次，GET請求結果都不變。

                          （至關於只讀，你只有讀結果 eg: get news list  /  get current time stamp  可能返回內容有變壞，可是獲得結果 就是目標新聞列表/當前時間戳 ）

        POST 非冪等性： 不論調用多少次，都將是產生新的資源 （至關於新建）

        PATCH 非冪等性：PUT方法的補充，用來對已知資源進行局部更新，更新屢次，就會請求屢次 好比只執行一次累加，可是不當心觸發屢次求，累加結果會不斷變化 （按需更新）

        PUT 冪等性：操做主要用來替換所有的資源，並且其實冪等的。（用替換的形式來實現更新效果，每次都得把所有內容都寫一遍，全部有了補充的PATCH）

       DELETE 冪等性：請求刪除目標資源，結果都是一個結果「刪除」，所以是冪等的

  2.2 遵照RESTful  設計規則 選擇 Http 請求方式

 （1）POST & PUT & PATCH  使用區別

          若是是昨天以前，有人這麼問我，我可能只會簡單回答一兩句：「POST 是向服務端寫入資源，PUT 是更新所有資源，PATCH 是更新指定資源」  好像也說不出更多的花花樣了。

         那麼如今我就會從冪等性和 RESTful 設計約束角度多說一點。

        「POST 從冪等性質來說 是非冪等的，使用POST 請求會明確可知這一點，每一次POST請求結果都會建立新的資源（關鍵在建立新的 非冪等）」 

        「PUT 是冪等的 是所有替換更新資源。（關鍵是在更新所有 冪等）」 

        「PATCH 非冪等性 是更新部分資源」

        「看似有些時候 用哪一種請求都尚可的狀況，從尊重RESTful 協議角度，若是你明確這個api 須要資源冪等性，那麼就應該設計使用PUT 的請求方式，這樣來直觀明確表達。」

（2）GET & POST 使用區別

       若是是昨天以前，有人這麼問我，我可能也是一兩句回答：「GET 請求是沒有請求body 直接url 明文獲取資源 ，而且 url 長度還有限制  POST 請求是向服務端寫入資源 有請求body POST 請求相對比 GET 更安全 由於body信息不在url裏體現」。這樣子

        今天 我就能夠從冪等性來進一步說明這個區別

        「 GET 是冪等 適合作查詢操做 POST 非冪等，適合作建立新增操做」

        「若是均可以的時候，由於GET 請求參數都要寫在URL 裏 有明文 和 長度限制的特色」

        「這個時候能夠選擇使用POST 來進行’查新’的折中方案，不會在url 中體現參數，也規避了url 的長度限制 雖然POST 非冪等，但方案折中符合要求 」。

        

      參考 

1. https://blog.csdn.net/SasukeN/article/details/80919889
2. http://www.javashuo.com/article/p-gpxpexmb-kh.html
3. https://blog.csdn.net/qq_33489669/article/details/56479485