1. 程式人生 > >iOS 學習 RESTful 中 Http 的冪等性

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. https://www.cnblogs.com/duhuo/p/4245202.html
  3. https://blog.csdn.net/qq_33489669/article/details/56479485