理論與例項，準確理解REST的無狀態設計

rest含義為」表述性狀態轉移」, 基於rest的web服務遵循一些基本的設計原則, 比較難理解的是伺服器端的請求應該是無狀態的。

1）通過 uri 來標識資源:

系統中的每乙個物件或是資源都可以通過乙個唯一的 uri 來進行定址，uri 的結構應該簡單、可**且易於理解，比如定義目錄結構式的 uri。

2）統一介面：

建立建立、檢索、更新和刪除操作與 http 方法之間的一對一對映：

若要在伺服器上建立資源，應該使用 post 方法；

若要檢索某個資源，應該使用 get 方法；

若要更新或者新增資源，應該使用 put 方法；

若要刪除某個資源，應該使用 delete 方法。

3）資源多重表述:

uri 所訪問的每個資源都可以使用不同的形式加以表示（比如 xml 或者 json），具體的表現形式取決於訪問資源的客戶端。在 rest 的世界中，資源即狀態，每個網頁是其乙個狀態；uri 是狀態的表述；rest 風格的應用則是從乙個狀態遷移到下乙個狀態的狀態轉移過程。早期網際網路只有靜態頁面的時候，通過超連結在靜態網頁間瀏覽跳轉的 page->link->page->link… 模式就是一種典型的狀態轉移過程。

4）無狀態:

客戶端對伺服器端的請求應該是無狀態的，請求不要求伺服器在處理請求時檢索任何型別的應用程式上下文或狀態。無狀態約束使伺服器的變化對客戶端是不可見的，因為在兩次連續的請求中，客戶端並不依賴於同一臺伺服器。

每乙個uri請求（例如網頁）理解為乙個狀態，那麼不同uri（網頁）間的跳轉可以理解為不同狀態之間的轉移。那麼這個狀態究竟如何實現轉移的呢？

很關鍵的理解：

狀態可以嵌入到應答訊息裡，這樣一來狀態在接下來的互動中仍然有效。

通過超連結實現有狀態互動，請求訊息的每次互動都包含完整的資訊。有多種技術實現了不同請求間狀態資訊的傳輸，例如 uri ，cookies 和隱藏表單字段等。狀態可以嵌入到應答訊息裡，這樣一來狀態在接下來的互動中仍然有效。

狀態記錄在服務端設計：restful的設計：由此可以看出，

rest 風格應用可以實現互動，但它卻天然地具有伺服器無狀態的特徵。在狀態遷移的過程中，伺服器不需要記錄任何 session，所有的狀態都通過 uri 的形式記錄在了客戶端。更準確地說，這裡的無狀態伺服器，是指伺服器不儲存會話狀態(session)；而資源本身則是天然的狀態，通常是需要被儲存的；這裡所指無狀態伺服器均指無會話狀態伺服器。

補充一點：

rest表述性狀態轉移，個人認為可以簡單理解為把服務端的狀態遷移到客戶端儲存或者資料庫端儲存，從而應用伺服器就可以設計成無狀態。所以文章標題更嚴格來說應該是「準確理解rest在應用服務端的無狀態設計」。

學習新技術，大致分兩個階段：

第一階段：了解這個東西是什麼，有什麼功能，什麼場景下使用

第二階段：這個東西為什麼是這樣的，功能原理是怎樣的，如何實現，如何做到

如果永遠停留在第乙個層次，那你永遠是技術的被動者，很難成為大師。現今浮躁社會的速成方法往往讓開發工程師停留在第一階段。

網上查了很多部落格介紹rest或者restful，基本沒有很滿意的文章，感覺大部分都是抄襲，沒有自己的理解。因為我看到的大部分是抄襲理論介紹，抄襲本無錯，關鍵是經常缺少基於自己理解的例子。

抓包工具fiddler使用與理論的理解

抓包工具fiddler使用與理論的理解 抓包工具是執行在本地，客戶端與伺服器之間的一層，可以很好的抓取兩者互動的資訊 關於http協議 http是乙個簡單的請求 響應協議，它通常執行在tcp之上 請求方法 url sql 附加資訊 reference cookie 響應為 響應頭 html 或其他資...

評測標準召回率Recall K的理解與例項解析

如圖 定義 總共紅色邊框為all negative 5 負樣本 總共藍色邊框為all positive 5 正樣本 top k推薦 從最後的按得分排序的推薦列表中返回前k個結果。precision準確率是檢索出相關結果數與檢索出的結果總數的比率，衡量的是檢索系統的查準率 recall k召回率是指前...

JAVA物件的例項化過程與多型的理解

原博文在 jvm 從jvm層面深入解析物件例項化 多型性實現機制 一.雖然看不懂位元組碼及棧分析，但至少理解到了兩點 1.this相當於指標變數，唯讀指標 2.物件例項化次序 可能是 2.1 this物件分配記憶體 父類和當前類成員變數獲得記憶體,父類方法載入，當前類方法載入，this變數賦值 2....