如何區分應用程序狀態和資源狀態

Question

我知道要創建無狀態應用程序，我們需要傳遞用戶狀態來回，而不是服務器保存用戶狀態。

但是，服務器中必須存儲一些狀態，我讀了這個article，這個存儲在服務器中的狀態稱爲資源狀態。所以如果我說得對，我們經常調用的客戶端狀態應該和應用程序狀態一樣。

那麼，我怎麼區分這兩個，因爲它會決定他們是否應該存儲在服務器或轉移。

以購物車爲例。

1. 如果有用戶前5個步驟來完成他的購買，用戶的階段時，他（＃3，＃4）似乎是一個應用程序的狀態，這是不是意味着，如果他們關閉瀏覽器並再次點擊工資，他將不得不從第1步開始？

2. 他的圖表中的項目怎麼樣？如果我們將其視爲應用程序狀態，則需要將所有項目放入請求中。但是，如果我們這樣做，當用戶關閉瀏覽器並重新登錄時，他將無法再次找到他的項目，因爲瀏覽器無法記住所有項目。所以我們應該將其視爲資源狀態。但是，如果是這樣，當用戶點擊付費時，他們將擁有不同的頁面：根據購物車是否爲空來付款或說「您的購物車是空的」。因此，具有完全相同的參數輸入的相同請求出現了不同的結果，我們仍然可以說它是無狀態的嗎？

也許我理解錯了什麼，任何人都可以回答如何區分不同類型的狀態以及如何區別對待它們？

Answer 1

資源狀態是一種狀態，即使在客戶端斷開連接/重新啓動/會話結束/任何事情之後，該狀態仍需要持續存活。 應用程序狀態應該位於客戶端上，並且應隨每個客戶端請求一起提供（如果我們正在討論REST體系結構並計劃好擴展我們的應用程序）。

如何區分應用程序狀態和資源狀態？

這取決於你正在處理的任務。例如。如果您試圖找出當前在圖庫中查看的圖片索引的位置，可能可以在您的應用程序狀態下執行該操作，因爲您可能不需要這個狀態以便在下一個會話中存活的客戶。當然，你可以將它保存在你的資源狀態（數據庫）中，但是它會是開銷（爲獲得非常小的收益需要很多努力）。

但是，如果您正在進行多步驟採購流程，可能最好將您的資源狀態（數據庫）中的此過程狀態保存下來，因爲您希望永久保存此狀態。否則，您的客戶需要在斷開連接/重新啓動/無論何時重新填充大量信息。 當然，你可以在cookie中做到這一點（這將是應用程序狀態），並且此狀態可以在瀏覽器重新啓動後生存。但它有兩個缺點：1）這種狀態在其他用戶的設備上不可用，2）如果您正在創建真正的REST服務，Cookie會使客戶的生活複雜化，因爲並非所有客戶端都運行得很好（瀏覽器除外）。

Answer 2

且讓我舉這本書RESTful Web Services的一個段落：

Flickr的 Web服務，您可以上傳圖片到您的帳戶，那些照片都存儲在 服務器。這將是瘋狂的，使客戶端發送其畫面中的每一個與 每個請求flickr.com一起，只是爲了讓服務器不必存儲任何狀態

的應用程序狀態是關係到客戶可以遵循的路徑來做出一些行動。 例如，在諮詢一篇文章時，會出現一個「添加到購物車」的鏈接。當諮詢他的購物車時，如果您的購物車中有一篇文章，則會提供鏈接「支付訂單」，否則此鏈接不會顯示。根據他所遵循的鏈接，請用戶自行製作應用程序狀態。基本上，應用程序狀態是上下文的問題。從早期mentionned之前，我回去給你例子同一本書

另外一個報價：

資源狀態保持在服務器上，是 只表示的形式發送到客戶端。應用程序狀態保留在 客戶端上，直到它可用於創建，修改或刪除資源。然後它作爲POST，PUT或DELETE請求的一部分發送到 服務器，併成爲資源狀態。

因此，假設您有一些認證機制（基於令牌）。並且將一個用戶帳戶關聯到一個購物車。 當您在購物車中添加物品時，您正在修改購物車資源。由於資源狀態是服務器端，它在服務器上。
假設您斷開連接並重新連接，如第一點所述。購物車仍然在這裏。
只要客戶端在每次請求時發送不同的認證證書，您的應用程序就保持無狀態。

有關如何管理它所以一個好的討論：Do sessions really violate RESTfulness?

現在，有關的事實是：諮詢你的車可以帶你到2個不同的動作取決於它是否有項目或沒有。
很簡單。服務器向客戶端提供的服務取決於服務器維護的資源狀態。
this good website上的一個非常簡單的例子。您可以看到，根據帳戶上的金額數量，服務器會提供一個鏈接給客戶進行退出或不退出。
請隨時向客戶提出自己的申請（再次），並遵循鏈接與否。

我建議你看看HATEOAS和解釋它的Richardson Maturity Model。 順便說一句，來自2段的引用來自同一作者，這個模型。