我正在閱讀Pro Spring MVC一書中的Spring Web Flow章節。不幸的是,沒有明確的信息,流程執行期間的狀態持續存在。我假設它保存在JVM堆中並與會話關聯。在服務器上使用沒有狀態的Spring Web Flow
現在HTTP是一個無狀態協議(REST ...),我想在不保存服務器狀態的情況下使用Spring Web Flow(除了可以驗證會話的唯一狀態外)。
一個策略是發送整個流程的所有參數與流量(隱藏輸入)的每個HTTP請求,並因此累積所有必要的參數,直到流程完成。
重新驗證參數的開銷可以通過簽名覆蓋已經驗證的參數來避免。
您是否知道,是否有可能以這種方式使用Spring Web Flow?有人已經這樣做了嗎?
更新:爲什麼?
堅持國家不僅違反了HTTP作爲無狀態協議的原則,但也有實際問題:
- 如果用戶使用多個瀏覽器標籤瀏覽那麼這可能會導致不一致的狀態,競爭條件或數據丟失。
- 在服務器上存儲狀態使多個服務器上的負載平衡更加複雜。
- 測試和調試變得更加複雜,因爲無法單獨測試或分析請求,而只能在以前的請求的上下文中進行分析。
- Cookie必須啓用才能將服務器會話與請求關聯起來。
- 服務器需要同步對服務器端狀態的訪問。
- 也取決於服務器狀態的請求的url不包含爲流中的狀態添加書籤或在錯誤報告中理解它的所有必要信息。
我還沒有看過Web Flow的細節,但我確信可以有相同的編程經驗,並且仍然保留請求參數中的所有信息。
更新:我已經瞭解到,我所要求的流動處理風格有一個名稱:Continuations。術語continuation在函數式編程中更常見,但將這個想法適配到HTTP交互中顯然並不少見。
你爲什麼想這麼做?你有太多的會話需要堅持嗎? –
使用Spring WebFlow的主要原因之一是它通過使用流提供_conversational state_。這些流程本質上將維護服務器端狀態以執行其功能。如果你想開發一個無狀態的應用程序 - 那麼我不認爲WebFlow是你想要的。對於REST風格的Web服務,您最好使用常規的Spring-MVC或其他一些技術,如[Jersey](https://jersey.java.net/)。 –
我可以告訴你,在某些時候,你可能會遇到WebFlow的性能和數據不一致問題,因爲WebFlow中的每個狀態/數據都是序列化/反序列化的。通過WebFlow中的許多REST請求和數據操作,您將很容易遇到這些請求之間數據不一致的問題,難以調試和複製的錯誤。 –