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