[Architecture] 註銷:GET還是POST?


Answers

使用POST

在2010年,使用GET可能是一個可以接受的答案。 但是今天(2013年),瀏覽器會預取他們“認為”你將訪問的頁面。

這是一個在Twitter上討論這個問題的StackOverflow開發人員:

我想感謝我的銀行註銷GET請求,並感謝Chrome團隊提供便捷的URL預取@Nick_Craver Nick Craver( @Nick_Craver2013年1月29日

有趣的事實:StackOverflow用於處理通過GET登出,但不再。

Question

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

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

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

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

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




GET可能會被濫用的一種方式是,一個人(競爭者或許:)在互聯網上放置了一個帶有src="<your logout link>"的圖片標籤,並且如果你的網站的用戶在該頁面上絆倒,他將會在不知不覺中註銷。




為了正確,GET / POST(或其他動詞)是對某些資源(由URL尋址)的操作 - 所以它通常關於資源的狀態,而不是關於應用程序狀態。 因此,在真正的精神,你應該有一個URL,如[host name]\[user name]\session ,然後'刪除'將是註銷行動的正確動詞。

使用[host name]\bla bla\logout作為URL並非真正的REST完整方式(IMO),那麼為什麼要爭論正確使用GET / POST呢?

當然,我也在我的應用程序中使用GET來註銷url :-)




您好我的觀點是,當您登錄時檢查用戶名/密碼,如果這些匹配,則創建登錄令牌。

CREAT token =>方法POST

當您註銷時,您會破壞令牌,因此對於我來說最合乎邏輯的方法應該是DELETE

DELETE token =>方法DELETE




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




我看不出如何註銷(降低用戶權限)是一種破壞性行為。 那是因為“註銷”操作應該只對已經登錄的用戶可用,否則它將被廢棄。

瀏覽器cookies中包含的隨機生成的字符串全部代表您的用戶會話。 有很多方法可以銷毀它,所以有效登出僅僅是為您的訪問者提供的服務。




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

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

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

菲爾德論文 - 第5.1.3節

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




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




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

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

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