ACM_Someone like you

一. 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 的請求方式，這樣來直觀明確表達?！?/p>

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