REST架構設計是目前非常火熱的概念，已經成為構建web服務時應該遵循的事實標准。REST約束中有一條很重要的規則是“無狀態”，但“無狀態”是個很抽象的概念，對剛剛接觸的人來講，很難深刻形象的理解。今天在網上看了一篇文章，對於“無狀態”的解釋感覺很容易讓人理解，特把文章中相關內容整理了下。
-
"狀態"的概念是什么
一個Web應用程序協議的“狀態”在通常指的是為兩個相互關聯的用戶交互操作保留的某種公共信息，它們常常被用來存儲工作流或用戶狀態信息等數據。這些信息可以被指定不同的作用域如page，request，session或全局作用域，而存儲他們的責任也同樣可以由Client端或Server端負責。
服務調用過程中有兩種“狀態”：應用狀態(Application State)和資源狀態(Resource State)。應用狀態指的是與某一特定請求相關的狀態信息，而資源狀態則反映了某一存儲在服務器端資源在某一時刻的特定狀態，該狀態不會因為用戶請求而改變，任何用戶在同一時刻對該資源的請求都會獲得這一狀態的表現（Representation）。RESTful架構要求服務器端不保有任何與特定HTTP請求相關的資源，所以應用狀態必須由請求方在請求過程中提供。
例如session ID可以被認為是一個用來標識某一會話狀態的Key，將其傳遞給服務器端意味着這樣一個請求：“請幫我取出這個狀態信息”，也就是說這個請求假設響應方保有着狀態信息。由於與某一特定請求相關的狀態屬於應用狀態，而RESTful架構要求任何此類狀態由請求方負責提供，所以傳遞Session ID被認為是unRESTful的做法。而用戶的身份憑證信息作為一種應用狀態，是被期望由請求方提供的，所以在請求中傳遞用戶的身份憑證信息是符合RESTful架構規范的。
-
為什么要使用無狀態的架構
雖然存儲狀態為企業軟件開發帶來了諸多便利，但是它也給分布式系統的其他方面帶來了許多限制，比如在負載均衡方面，在有狀態的模式下，一個用戶的請求必須被提交到保存有其相關狀態信息的服務器上，否則這些請求可能無法被理解，這也就意味着在此模式下服務器端無法對用戶請求進行自由調度。於此相關的另一個問題是容錯性，倘若保有用戶信息的服務器宕機，那么該用戶最近的所有交互操作將無法被透明地移送至備用服務器上，除非該服務器時刻與主服務器同步全部用戶的狀態信息。此外，由於HTTP本身不是一個有狀態的協議，開發人員必須通過模擬實現狀態的鈍化與激活等。於是為了克服這些不足，無狀態(Statelessness)架構風格屬性受到了廣泛關注。
-
無狀態即各自維護自身的狀態，如會話信息都在客戶端，服務端並不保存狀態信息，那么我們可以說服務端是無狀態的，這個的好處是顯而易見的，無狀態的部分可以很方便的被替換掉（或集群、橫向擴展）而不用狀態重建（或同步），大大提高了可申縮性(scalability);通常J2EE的session被認是不好的設計，大部份J2EE中間件在集群時都需要進行session同步，而Play!並非基於J2EE體系設計的，則沒有該煩惱！