最近讀了http的入門書籍《圖解HTTP》，雖然仍然是一知半解，但是總得寫點東西加深一下印象。

語義 http協議是基於tcp協議的應用層協議，tcp協議作為可靠的傳輸層協議，因此http協議也是可靠的。

日常開發過程中，最常用的是get post put delete，在http協議的規定中，這四個method屬於標準的crud，分別代表了增刪改查，存在著語義上的差別。

當然你要是樂意的話，用post獲取，用get去做增改也是可以的。只不過不推薦如此罷了。

因為主要是語義上的差別，因此在傳輸層上來看的話，get和delete post和put是沒有任何區別的。不過把應用層協議放到傳輸層上來看，本身就是一件比較扯的事。

值得一提的是在部分瀏覽器下，post會發送兩個資料包，get只發送一個。這也是有些文章推薦全部用get做優化，不過大部分專案規模都不大，這點優化帶來的效能提升幾乎看不見。

冪等性 冪等性的概念來自於數學（好像程式設計都是來自數學，數學家最厲害，研究出來一些東西之後，各位大牛實現成拓展，我們這種去用一下，不求甚解）。

冪等性指的是相同引數的重複執行，獲得的副作用都是一致的。譬如get方式獲取某個帖子，帖子id不變的話，造成的副作用肯定是一致的，自然是符合冪等的。需要注意的是，這裡強調的是相同的副作用，並不是相同的內容。譬如帖子被刪除了，再次訪問肯定是沒有結果的，但是造成副作用仍然是一致的。

同理，無論是put方法去更新一個帖子，還是delete方法去刪除一個帖子，無論執行多少次，副作用也全部是一致的。自然也是冪等的。

post方法是最奇特的，畢竟是建立一個帖子，在建立之前，自然不可能得知這個帖子的id。另外三種都是對應資源的uri，唯有post對應的是建立資源的實體。如果訪問多次，那麼就會建立多個帖子，造成的副作用是不一樣的（對應的帖子的id發生了變化，就像往資料庫插入相同的記錄，id是一直在自增的）。也就是說post不是冪等的。

不過有很多方法去避免這個情況的發生：可以在先生成一個隨機字串存到session、並且埋在表單的隱藏域中，接收到表單提交的資料之後，首先檢測這個隨機字串是否存在，如果存在就驗證通過、並刪除該session，不存在即可認為是重複提交。

還有個思路，在表單提前埋入一個ticket，這個ticket直接和當前操作繫結，提交之後先去判斷該ticket是否已經使用，未使用就建立一個資源，已使用就不進行操作。這個ticket肯定要做持久化儲存，不過相對於帶來的好處，這點資源的消耗是完全可以接受的。

從網上找了一個圖：

RESTful 先說下關於restful的概念

1、網路上的所有事物都被抽象為資源（resource）；

2、每個資源對應一個唯一的資源標識（resource identifier）；

3、通過通用的聯結器介面（generic connector interface）對資源進行操作；

4、對資源的各種操作不會改變資源標識；

5、所有的操作都是無狀態的（stateless）。

RESTful是一種架構設計風格，提供了設計原則和約束條件，而不是架構。而滿足這些約束條件和原則的應用程式或設計就是RESTful架構或服務。是基於http（RPC 是基於TCP協議的）建立的一種介面規範，核心就是資源。目前api開發中，最常用的就是RESTful風格，也就是採用了這個機制。僅僅是看一下這個url就能猜測出對應的方法的作用，省去了大量的理解介面之間邏輯的時間。最大的好處由於RESTful強制所有的操作都必須是stateless的，這就沒有上下文的約束，如果做分散式，叢集都不需要考慮上下文和會話保持的問題，極大的提高了可伸縮性。 ---------------------  作者：從別後  來源：CSDN  原文：https://blog.csdn.net/cs958903980/article/details/52817116  版權宣告：本文為博主原創文章，轉載請附上博文連結！