已開始使用新項目，該項目聲稱具有RESTful Api。我看到的一種常見模式是沒有任何傳入正在進行身份驗證。無論何時需要，會話對象都被用來獲取用戶信息。
當我與負責人交談時，他告訴我爲每個請求創建一個用戶會話非常昂貴。這個實現背後的想法是向數據庫發送一個請求來驗證用戶。當會話對象已經存在時，這是非常耗時和不必要的。
我不能說更多的不是stateless實現，它違背了REST哲學。
其他概念：系統是否應驗證會話的每個請求
不使用此類設計實現的其他實際原因是什麼？
REST的無狀態並不意味着服務器無法存儲狀態。大多數服務都有很多狀態存儲在數據庫中。使用數據庫以外的東西沒有什麼問題，比如大多數會話存儲的分佈式內存中緩存。
什麼樣的無狀態意味着客戶端不應該認爲服務器記得關於以前通信的信息。每個請求應包含推斷其含義所需的全部信息。
一個典型的例子是FTP服務器，它接受像「cd somedir」這樣的命令。隨後假定所有後續操作發生在這個目錄中。這在RESTful意義上不是無狀態的，因爲後續消息的含義依賴於前一個消息。這可以很容易地通過讓每個命令包含其當前工作目錄來解決。
現在，如果你看看你的情況，你發送一個會話標識符與每個請求，這是用來查找身份驗證信息。由於這些信息在每個請求中都被傳遞，所以實際上可以認爲這個構造是無狀態的，具有RESTful的意義。
當然，這是違反REST架構風格的。真正的問題是，如果你們中的任何一個人明白爲什麼，如果負責人做出有教養的決定，權衡是否值得，是否同意或不同意。這是你們倆應該進行對話的基礎。個人而言，我可能會建議將auth數據粘貼到數據庫緩存中並保持無狀態是確保當前性能和未來可伸縮性的更好方法，但我當然對系統一無所知。
一個不認爲你描述的設計有什麼問題，它實際上在單頁應用程序時代是非常普遍的。
但回答你的問題，爲什麼REST被定義爲無狀態的一個重要原因是可伸縮性。當您使用服務器會話存儲身份驗證信息或任何與服務器相關的存儲王時，您必須在羣集環境中的其他節點上維護它。如果您有2+節點，則它們必須共享或複製授權存儲（通常是會話），或者強制一個用戶與同一個節點通信，這稱爲「粘性會話」。或者您可以將兩種技術結合使用，以便關閉一個節點而不影響用戶使用它。
很明顯，當你擁有真正的無狀態API時，你不需要這個。從我的觀點來看，對於獨立Web服務使用SPA後端和無狀態身份驗證可以使用狀態驗證。但那裏沒有直線。