簡而言之，如何設計使用者登入？
實在找不到了，只能在這裡求老師 ~
api server 如何處理 authentication 其實和 rest 怎麼設計沒什麼直接關係，rest 只是一種針對基於 http 的應用（即 web 應用）進行資源管理的設計原則，或者說就是指導你如何安排資源的一種設計理念而已。
至於處理使用者認證（登入等），那是在 rest 設計完了之後的事情，屬於伺服器端的應用業務邏輯。
換言之，不管你如何設計（是否 rest，或者 rest 的正不正確，徹不徹底等等），都不會影響你處理使用者認證的業務邏輯，這根本就不是非此即彼的事情。
但是很多人搞不清楚這一點，以為實踐了 rest（更不要說大部分實踐都是錯的，或者不夠徹底的）就一切都和以前不同了，甚至以為一旦用了 rest，任何事情（比如身份認證）都有且僅有一條正確的路可走了……這一點真有些哭笑不得。
以本問為例我們來做乙個分析吧。
首先，伺服器端的身份驗證基本上有兩類方式：一是基於 cookie 的驗證，一是基於 token 的驗證。選擇哪一種要看你的實際情況。基於 cookie 的驗證歷史悠久了，原理和做法無需贅言；近幾年湧現了大量的公共 api 服務，它們基本上都使用了基於 token 的驗證，這主要是因為：
處理跨域資源分享（cors）——雖然 cookie＋cors 也不是完全不可能，但是比較難搞
無狀態性——有利於服務端擴充套件（伸縮性強）
c/s 解藕——伺服器端和客戶端可以完全分離，進而靜態資源可以用 cdn 來處理，伺服器端完全變成 api service
csrf free——不依賴 cookie，完全不擔心跨域偽造請求攻擊
……呃，忽然覺得有點跑題了，我的意思是你首先得選擇乙個驗證方式，很明顯基於 token 的認證是趨勢。
接下來，假定選擇了基於 token 認證這條路，你首先得搞明白 token 是怎麼玩的。簡單地說：客戶端先傳送正確的認證資訊（比如電子郵件＋密碼），伺服器端檢查 ok 之後生成乙個 token 返回給客戶端，之後客戶端所有的請求都要包含這個 token，伺服器端只需要驗證該 token 是否有效即可。這裡有一張圖，對比了 cookie－based authtication 和 token－based authentication，挺不錯的：
好，按照 rest 的設計原則，我們需要乙個 endpoint 供使用者來請求認證並獲取 token，比如像這樣：
post /authentication
在這裡，「資源」就是認證（按照 rest 的要求，用名詞來表示資源），使用post方法去請求，附帶資料為認證用的資訊，返回結果看你的業務邏輯，但至少要有乙個 token。客戶端拿到 token 之後，先把它存起來（比如存到 sessionstorage 裡），設定請求時的 header 裡authorization的值為bearer，完事了。
綜上所述，這事和 rest 的關係也就是設計乙個獲取 token 的 endpoint 而已，沒啥了不起的，剩下的事情都屬於業務邏輯，該怎麼寫就看你的需求了。
如何使用Spring優雅地處理REST異常
1.概覽 在spring 3.2之前，spring mvc應用程式中處理異常的兩種主要方式是 handlerexceptionresolver或註解 exceptionhandler。這兩種方式都有明顯的缺點。在3.2之後，我們有了新的註解 controlleradvice來解決前兩個解決方案的侷限...
如何安全地儲存密碼？
用 bcrypt 用bcrypt 用bcrypt 用bcrypt 用bcrypt 用bcrypt 用bcrypt 用bcrypt 用bcrypt 重要的話就是要多多地重複幾次 這些都是通用的hash函式，設計的初衷是為了盡可能快的計算大量資料的摘要。這意味著它們在保證資料完整性方面非常優秀但是對於儲...
如何安全地整合混合雲？
幾乎十分之九的it決策者認為，對於想要實現數位化業務轉型的企業組織來說，混合雲能力 很重要 或 很關鍵 2015年，新網際網路使用者的數量增長了8 增加0.25億人。許多企業組織期望適應不斷湧入的與本公司聯絡的全球客戶及其裝置，為此將資產遷移到雲端已成為當務之急。畢竟，雲計算可以降低成本，提高靈活性...