[Architecture] 註銷:GET還是POST?


Answers

在REST中不應該有會話,因此沒有什麼可以銷毀的。 REST客戶端會根據每個請求進行身份驗證。 登錄或退出,這只是一種幻想。

你真正要問的是,如果瀏覽器繼續發送每個請求的認證信息。

可以說,如果你的應用程序確實造成了登錄錯覺,那麼你應該能夠使用JavaScript“註銷”。 不需要往返。

菲爾德論文 - 第5.1.3節

客戶端到服務器的每個請求都必須包含理解請求所需的全部信息,並且不能利用服務器上存儲的任何上下文。 會話狀態因此完全保留在客戶端上

Question

這個問題不是關於何時使用GET或POST; 它是關於哪個建議用於處理Web應用程序的註銷。 從一般意義上,我發現了大量有關GET和POST之間差異的信息,但我沒有找到針對這種特定情況的明確答案。

作為一個實用主義者,我傾向於使用GET,因為實現它比POST更簡單; 只需放下一個簡單的鏈接即可完成。 這似乎是我能想到的絕大多數網站的情況,至少從我的頭頂來看。 即使堆棧溢出處理使用GET註銷。

讓我猶豫的事情是,儘管有些網絡加速器/代理通過檢索頁面中的每個鏈接來預緩存頁面,但用戶在點擊它們時會得到更快的響應。 我不確定這是否仍然適用,但如果是這種情況,那麼從理論上講,具有這些加速器之一的用戶只要登錄就會被踢出應用程序,因為她的加速器會找到並檢索註銷即使她從未點擊過該鏈接。

到目前為止,我讀過的所有內容都表明POST應該用於“破壞性行為”,而不會改變類似應用程序查詢等內部狀態的行為應該用GET來處理 。 基於此,這裡真正的問題是:

註銷被認為是破壞性行為的應用程序/是否會改變應用程序的內部狀態?




預緩存的場景是一個有趣的場景。 但我猜測,如果很多網站公司不擔心這個,那麼也許你不應該這樣做。

或者也許鏈接可以在JavaScript中實現?

編輯:據我了解,技術上GET應該是只讀請求,不會改變應用程序狀態。 POST應該用於改變狀態的寫入/編輯請求。 然而,其他應用程序問題可能更喜歡通過POST對GET進行一些狀態更改請求,我不認為這有任何問題。




註銷對應用程序本身沒有任何影響。 它改變了用戶與應用程序相關的狀態。 在這種情況下,看起來您的問題更多地基於如何從用戶發起命令來開始此操作。 由於這不是“破壞性行為”,因此確保會話被放棄或銷毀,但您的應用程序或數據都不會被更改,允許這兩種方法啟動註銷過程並非不可行。 該帖子應該被任何用戶發起的操作使用(例如 - 用戶點擊“註銷”),而get可以被保留用於應用程序發起的登出(例如 - 檢測潛在用戶入侵的異常通過註銷GET強制重定向到登錄頁面)。




那麼如果你讓你的web應用程序通過註銷腳本放棄會話,你通常也不需要。 通常,會話變量對於要放棄的會話是唯一的。